Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 368879

Summary:	CDT should force English messages from GCC
Product:	[Tools] CDT	Reporter:	Markus Milleder <Markus.Milleder>
Component:	cdt-build	Assignee:	cdt-build-inbox <cdt-build-inbox>
Status:	RESOLVED WONTFIX	QA Contact:	Andrew Gvozdev <angvoz.dev>
Severity:	normal
Priority:	P3	CC:	cdtdoug
Version:	8.1.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Markus Milleder

2012-01-17 15:54:48 EST

Build Identifier:

When the locale settings of a system are set to a non-English locale, GCC will use that non-English language for its messages.

This confuses both the path discovery of the indexer and the error parser.

Since English messages are necessary for correct operation of CDT, CDT should automatically set LC_MESSAGES=C for any invocation of GCC.

Happened to me with Eclipse Indigo (SDK + CDT; M20110909-1335) on Windows 7 Ultimate 64bit, where the regional settings get used despite setting the interface language to English :-(

Happened both with Cygwin and MinGW. Took some googling to find the problem.

Workarounds:
* Define LC_MESSAGES=C in each project's settings - annoying with more projects
* Define LC_MESSAGES=C in the Windows environment - hits all Windows programs as well
Defining LC_MESSAGES=C in the Cygwin/MinG startup files only helps if Eclipse is always started from the shell prompt.
(* Delete **/*.mo - brutal, hits all Cygwin or MinGW programs, needs to be repeated after updates of the installation)

Bug: At least the silent failure in face of non-English messages is a bug, even if asking for the concrete action of setting LC_MESSAGES=C is an enhancement request.

Severity Normal: while the workaround is easy, finding out what is wrong is likely quite hard for newbies, leaving a first impression of "CDT does not work".

Reproducible: Always

Steps to Reproduce:
Windows
1. Set some non-English regional settings (e.g. German/Austria)
2. Start Eclipse
3. Create a new workspace
4. Create a Hello World C project
5. Note that the indexer dose not find stdio.h
6. Note that a build is successful

Linux ($=shell prompt) [assuming message catalogs are installed]
1. $ export LC_MESSAGES=DE_de
2. $ eclipse
3.-6. follow the steps for Windows

Comment 1 Andrew Gvozdev

2012-01-17 17:47:03 EST

For scanner discovery this was fixed with bug 368622, and your steps won't produce indexer errors anymore.

You have a point with error parser but I am not convinced that forcing a different language on the user is a good idea. Anybody else has an opinion on that?

Comment 2 Doug Schaefer

2012-01-17 17:51:30 EST

(In reply to comment #1)
> For scanner discovery this was fixed with bug 368622, and your steps won't
> produce indexer errors anymore.
> 
> You have a point with error parser but I am not convinced that forcing a
> different language on the user is a good idea. Anybody else has an opinion on
> that?

I agree with you on that. We should be supporting non-English languages in everything we do, error parsing included.

Comment 3 Markus Milleder

2012-01-18 16:46:28 EST

(In reply to comment #2)
> (In reply to comment #1)
> > For scanner discovery this was fixed with bug 368622, and your steps won't
> > produce indexer errors anymore.

Andrew, thanks for finding the bug report I was obviously too confused to find :-(

> I agree with you on that. We should be supporting non-English languages in
> everything we do, error parsing included.

The error parser does not recognize translated warnings as warnings, adding them as errors in the Problems view.

So, I'd like to ask for a build system warning if GCC's locale is non-English.

I suggest detecting that by comparing the output of a gcc call without arguments between an invocation with default environment and one where the locale is set to "C". The best time to do so would likely be when doing discovery. (Compiling a test program that yields exactly 1 warning would yield the translation of "Warning", but writing such a program may be hard in the face of all the different GCC versions in common use.)

Feel free to reclassify or even close this bug - it's certainly only either minor or an enhancement request now.

Comment 4 Andrew Gvozdev

2012-01-19 16:13:31 EST

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > For scanner discovery this was fixed with bug 368622, and your steps won't
> > > produce indexer errors anymore.
> Andrew, thanks for finding the bug report I was obviously too confused to find
> :-(
Heh, I actually meant bug 304139 where it was really fixed.

> > I agree with you on that. We should be supporting non-English languages in
> > everything we do, error parsing included.
> The error parser does not recognize translated warnings as warnings, adding them
> as errors in the Problems view.
> So, I'd like to ask for a build system warning if GCC's locale is non-English.
To detect that locale is non-English it would suffice to inspect environment variables. However, there is a variety of ways how one could support native locales. The official way is to translate eclipse by Babel project. Error parsers keep their patterns in property file that is supposed to be externalized by Babel. So could do it like that. I am not sure that that is most transparent to a user though. Another way from the top of my head is to provide "language packs" for error parsers, and ISV could easily do that. If one is serious about it, the one should spend some effort to design it well from both UI and code design perspectives. I doubt anybody plans to do that any time soon.
In either case, a warning that locale is non-English is at odds with these potential solutions.

> Feel free to reclassify or even close this bug - it's certainly only either
> minor or an enhancement request now.
Alright, I close it as WONTFIX.