Problem parse language

[nittka]

While investigating #175, I noticed that on my linux machine the console errors (in Elysium) were printed in English although in CompilerProcessBuilderFactory the environment variable LANG was set to de_DE (and hence German error strings were expected). Compiling via command line printed German error messages - LANG was set to de_DE.UTF-8 there.

Appending ".UTF-8" to the locale in CompilerProcessBuilderFactory resulted in German error messages in the console as well (and did work in Windows as well).

However, trying to set any other locale for Linux directly (for French, Italian, ...) always produced English error messages (both on command line and in Elysium), so I was not able to play around with other languages.

I propose two changes:

• add the ".UTF-8" suffix in CompilerProcessBuilderFactory when setting LANG
• always use English as a fallback when trying to determine the Severity in ProblemParser (althogh the locale suggests a particular error string, setting the locale for the command may not have had an effect).

@thSoft: while briefly browsing, I did not find out where LilyPond stores its translation files or how to find out the supported languages. If you know something in that direction, let me know. Also it might make sense, not to determine the language from the locale but rather from the console output directly. E.g. for German "Analysieren ..." is printed rather than "Parsing ..." in English. If we had these marker phrases for the other languages supported by ProblemParser (and if they were unique), we would have a safer way for determining the language actually used for compilation.

edit: see https://github.com/lilypond/lilypond/tree/d6bfb4fabdaa03720ad3d1873ff71c330f3ac9ba/po for translation files and the "lilypond.mo" files in /usr/share/locale. However, even though the translation files seem to be present on my Linux system, even on the command line exporting LANG, I do not get LilyPond to use any other language than German or English; for Windows I can check potential changes.

[nittka]

The main problem of #175 is found (incompatible Guava version cause an exception preventing the problem parsing). The immediate cause will be dealt with in #179. However, the question remains whether we should determine the language from the compiler output rather than from the locale (hoping that LilyPond really used the one we set in the environment.

This will involve quite some refactoring (in the problem parsing). Do you want me to make this change? And if so which version:

• as now but always try English fallback as well
• completely locale independent implementation (guess language from marker phrases, will have performance impact but it should not be too bad, because once the language is determined, no further guessing is necessary)

[thSoft]

• I think the English fallback is sensible based on LilyPond's behavior you observed.
• I would rather not depend on LilyPond's messages.
• An alternative could be to query the used locale from LilyPond. This could be done by having LilyPond evaluate a Scheme expression with the --evalute command line argument which prints the used locale. Unfortunately, I don't know LilyPond's Scheme internals that much, and they are undocumented.

[nittka]

I am not sure evaluating a Scheme expression would work. My conjecture is that exactly that exactly the locale set in the command builder would be returned. The localisation will not be done by LilyPond but by some "operating system component".

I think, for now I will just go for the English fallback variant. If somebody is not happy with the problem marker parsing, a new ticket can be opened.