This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin started speaking German today


On 9 September 2011 16:13, Charles Wilson wrote:
> On 9/9/2011 8:33 AM, Andy Koppe wrote:
>> On 9 September 2011 10:18, Charles Wilson wrote:
>>> #2, some older versions of the base-files startup
>>> scripts (/etc/profile, /etc/skel/.*, and the like) used to set LANG or
>>> LC_* IIRC. ÂHowever, they no longer do so
>>
>> Actually, that is still done, in /etc/profile.d/lang.sh. It's for the
>> benefit of other programs who think they know better than the system
>> (emacs, I'm looking at you) by analyzing LC_* and LANG themselves
>> instead of relying on setlocale().
>
> Ahh, I did 'grep' not 'grep -r'. ÂOops.
>
>>> If /no/ relevant env vars are set
>>> then
>>> Â Â Â Âif setlocale(LC_*, "") returns C.UTF-8
>>> Â Â Â Â# which we know is the /current/ cygwin default locale
>>> Â Â Â Âthen
>>> Â Â Â Â Â Â Â Âquery Win32 API for "real" default locale
>>> Â Â Â Âelse
>>> Â Â Â Â Â Â Â Âuse what setlocale returns
>>> else
>>> Â Â Â Âuse the env var value; don't ignore 'C.UTF-8'
>>> Â Â Â Â# if I have explicitly set LANG=C.UTF-8 then I must really
>>> Â Â Â Â# really want the "C" locale, not en_US or de.
>>
>> Please, no. As Corinna said: "Do NOT call Windows functions in Cygwin
>> libraries, unless the lib is doing something very special which isn't
>> provided by POSIX functions. ÂOnly call POSIX functions. ÂDon't mix
>> the Cygwin and the Windows environment. ÂPlease leave the interfacing
>> to the underlying OS the sole job of Cygwin."
>
> "In the interim". ÂThat is, until cygwin itself is prepared to DTRT,
> allow libintl to pick up the slack.

Thereby pre-empting a design decision that is duly Cygwin's. Again:
"Do NOT call Windows functions in Cygwin libraries, unless the lib is
doing something very special which isn't provided by POSIX functions.
Only call POSIX functions.  Don't mix the Cygwin and the
Windows environment.  Please leave the interfacing to the underlying
OS the sole job of Cygwin."

Besides, your proposal wouldn't work, due to the LANG=C.UTF-8 setting
in /etc/profile.d/lang.sh. And if lang.sh was changed to pick up the
Windows setting, libintl wouldn't need to muck about with Windows
APIs.

> ÂThat's the only way I can see to
> satisfy both the mandates of cygwin (hide win32 from posix apps) and
> libintl (provide the most natural i18n experience to all users
> regardless of platform or language).

"Libintl is a library that provides native language support to
programs." It doesn that perfectly well without going against the
wishes of the platform maintainers. Users can choose a language by
setting LANG or LC_*, as documented in the Cygwin manual. In the
probably-soon-to-be-default "Cygwin Terminal", they can even choose
the locale in the options dialog.

> It boils down to the following: cygwin made a decision -- incorrectly
> IMO -- to explicitly set the default language/locale to "C", rather than
> allowing the system defaults, as established via the Regional Settings,
> to control i18n behavior //when the user has not specifically requested
> something else, for cygwin, via LANG=*//

That's certainly a valid opinion. Please take it to cygwin-developers
and try to convince Corinna to change that decision.

> Now, this might make sense in that it would allow old cygwin
> English-only installations to *keep* being english-only, without
> positive action from existing users. ÂBut, I doubt German-speakers, with
> Regional Settings set so that all pure-win32 progs speak German, would
> be hampered if cygwin suddenly started speaking German, too. ÂSurprised,
> maybe, but not hampered.

True. Nevertheless there'll be complaints, and I can't remember any
demands for this. Then again, complaints would be easy enough to deal
with.

> Ideally, cygwin will revisit this decision and add functionality to
> "translate" the win32 regional settings into appropriate setlocale(LC_*,
> "") behavior.
>
> But...*until that time*...it makes sense as a temporary measure to allow
> libintl to step in.
>
>> The 'C.UTF-8' default locale is not a bug, it was a deliberate design decision.
>
> If you have to hardcode a specific locale, then picking "C" -- and
> forcing the UTF-8 charset -- is a good idea. ÂBut...we don't *have* to
> pick a single hardcoded locale.
>
>> Of course a good case can be made for picking up the Windows language
>> in case none of LC_* and LANG are set, but there are also obvious
>> arguments against: translations are usually patchy, i.e. you end up
>> with a mix of English and translations of varying quality, which a lot
>> of people hate.
>
> So...because of bugs in the the translations of program X, Y, and Z, we
> should default to a "foreign" language (English) rather than expose
> those poor translations, or fix them? ÂIsn't this just papering over the
> problem?

Maybe, but that's not Cygwin's problem to solve.

> What do the linux distributions do? ÂIgnore language settings chosen in
> the Installer GUI, and force Chinese users to use English? ÂSomehow I
> doubt that.

They do indeed usually default to the local language. This prompts
questions like these from some users:

http://askubuntu.com/questions/11601/command-line-tools-in-one-language-system-in-another
http://superuser.com/questions/235764/ubuntu-errors-in-terminal-how-to-show-them-in-english-language

> holding libintl hostage to cygwin misfeatures is not helpful.

And that's not a helpful statement.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]