Translations of GNUCash into Konkani Language

[John Ralls]

On Mar 29, 2014, at 11:27 AM, Frank H. Ellenberger <frank.h.ellenberger at gmail.com> wrote:

> Am 29.03.2014 06:08, schrieb John Ralls:
>> I think you want to use kok for one and kok at roman or kok at devanagari for the other.
>> This RedHat bug is germane: https://bugzilla.redhat.com/show_bug.cgi?id=458949
> 
> From my understanding of http://en.wikipedia.org/wiki/BCP_47 and
> http://en.wikipedia.org/wiki/ISO_15924
> it should be kok-{Deva|Latn}.
> 
> But which is the default one and how to implement that? I believe Deva,
> Latin seems to be a reminiscent of Goas history.
> 
> Chandrakant, can you confirm that?
> What are your http://wiki.gnucash.org/wiki/Locale_Settings to run a
> program in konkani?
> 
> If we get a consense, a redhat user should update above bug.

I agree with your reading of BCP-47. But it’s not what applies here. IEEE Std 1003.1 (aka POSIX) governs, and it says [1]:

> If the locale value has the form:
> 
> language[_territory][.codeset
> ]
> 
> 
> it refers to an implementation-provided locale, where settings of language, territory, and codeset are implementation-defined.
> 
> LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , and LC_TIME are defined to accept an additional field @ modifier, which allows the user to select a specific instance of localization data within a single category (for example, for selecting the dictionary as opposed to the character ordering of data). The syntax for these environment variables is thus defined as:
> 
> [language[_territory][.codeset][@modifier
> ]]
> 
> 
> For example, if a user wanted to interact with the system in French, but required to sort German text files, LANG and LC_COLLATE could be defined as:
> 
> LANG=Fr_FR
> LC_COLLATE=De_DE
> 
> 
> This could be extended to select dictionary collation (say) by use of the @ modifier field; for example:
> 
> LC_COLLATE=De_DE at dict

See also [2] for the requirements of what must be present in a locale definition to keep setlocale() from reporting an error.

Once again, we’re not using setlocale() to retrieve messages, we’re using gettext.

Microsoft, of course, has their own locale designations [3], but those are important to us only when retrieving localization settings from the system.

Regards,
John Ralls


[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_02
[2] http://pubs.opengroup.org/onlinepubs/7908799/xbd/locale.html
[3] http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx