bugGNU gettext - Bugs: bug #43801, should use default language on...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #43801: should use default language on Windows, not default locale

Submitter:  Pierre Ossman <cendossm>
Submitted:  Thu 11 Dec 2014 10:46:03 AM UTC
   
 
Category:  End-user / runtime Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Jump to the original submission

Fri 12 Dec 2014 11:20:26 AM UTC, comment #7: 

I'm afraid I'm a bit too swamped with other things at the moment. :/

Pierre Ossman <cendossm>
Fri 12 Dec 2014 10:59:40 AM UTC, comment #6: 

Would you like to submit a patch along these lines?

Eli Zaretskii <eliz>
Fri 12 Dec 2014 09:36:10 AM UTC, comment #5: 

That sounds like it would work. It has one corner case though:

 - Locale is Swedish
 - Language is English
 - App really wants Swedish so it sets the thread locale to Swedish, hoping it will change the language.

But it's probably not worth worrying about.

Pierre Ossman <cendossm>
Fri 12 Dec 2014 09:28:52 AM UTC, comment #4: 

OK, thanks.  That makes sense.  The question is how do we cater to both use cases.

How about comparing the current locale to the default locale, and if they are different, use the locale; otherwise use the user UI language?  Would that DTRT?

Eli Zaretskii <eliz>
Fri 12 Dec 2014 09:08:47 AM UTC, comment #3: 

Engineers commonly set up the locale to their local one, but keep the language in English. So e.g. Swedish locale to get currency and units properly, but English as the language. It's very annoying when some applications then decide to show Swedish translations.

Pierre Ossman <cendossm>
Thu 11 Dec 2014 05:34:49 PM UTC, comment #2: 

I don't think this patch is correct.  The application could change the locale by calling SetThreadLocale (or any equivalent call, like the global setlocale), and after that it should get the translations according to that locale's language.  If we use GetUserDefaultUILanguage, there will be no way for the application to affect the current language and codeset through locale-related calls.  This is important in applications that change locales for various reasons (e.g., Guile does that).

So if we need to change here something, we will need a better understanding of the situation you had in mind.  Could you please describe the problem in more detail?  Exactly when would the locale's language and the language returned by GetUserDefaultUILanguage be in conflict, and how can this conflict come into existence?

Thanks.


Eli Zaretskii <eliz>
Thu 11 Dec 2014 12:33:33 PM UTC, comment #1: 

Sorry, I'm not familiar with the Windows stuff.  Adding Eli to Cc, who recently did some improvements on that part.

Daiki Ueno <ueno>
Group administrator
Thu 11 Dec 2014 10:46:03 AM UTC, original submission:  

A Windows user that has configured a different language and locale will get translations based on the locale for gettext programs rather than the chosen language. This is because gettext calls GetThreadLocale() instead of GetUserDefaultUILanguage().

Patch attached for 0.19.3. Might not be entirely correct though as the function is meant to get locale, not language. More restructuring might be needed.

Note that for Win32 you also need to set WINVER to 0x0500 to get this API as it was new for Windows 2000.

Pierre Ossman <cendossm>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Updated the item)
  • -email is unavailable- added by eliz (Posted a comment)
  • -email is unavailable- added by ueno (Posted a comment)
  • -email is unavailable- added by ueno
  • -email is unavailable- added by cendossm (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-27 haible CategoryNone End-user / runtime
    2014-12-11 ueno Carbon-Copy- Added -email is unavailable-
    2014-12-11 cendossm Attached File- Added gettext-0.19.3-langid.patch, #32649

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code