Issue 13735 - RFE: change language/locale identifier to standard convention
Summary: RFE: change language/locale identifier to standard convention
Status: CLOSED DUPLICATE of issue 8252
Alias: None
Product: Internationalization
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P2 Trivial with 10 votes (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@l10n
Keywords: oooqa
Depends on:
Reported: 2003-04-23 08:36 UTC by arthit
Modified: 2013-08-07 15:00 UTC (History)
4 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description arthit 2003-04-23 08:36:18 UTC
The Free Standards Group's OpenI18N Locale Name Guideline
Comment 1 arthit 2003-04-23 09:16:33 UTC
Current code (00.o 1.0.x, 1.1.x),
use "international calling code" number to
distinguish each language/locale from others.

For example in Glossary/UI strings of OO.o,

    1  for English (USA)
   81  for Japanese
   66  for Thai

Anyway, this kind of implementation has many limitations.
Two known issues.

1) "international calling code" actually represents "location", not

2) faces problem, when some "location" use more than one language.
   e.g. in Switzerland, people speaks German and French.
        in India, more than ten languages there.


Generally, in UNIX and most free software systems,
they use a xx_YY convention. Where xx is an ISO language code,
and YY is an ISO territory code.


   en     for English (no specific location/cultural data)
   en_US  for English (USA; "color", US Dollars, 6ft, ...)
   en_UK  for English (UK; "colour", Pound Sterling, 170cm, ...)
   ga_UK  for Irish (UK)
   en_CA  for English (Canada; CA Dollars, ...)
   fr_CA  for French (Quebec, Canada; CA Dollars, ...)
   de_DE  for German (Germany; EURO, ...)
   de_CH  for German (Switzerland)
   ja_JP  for Japanese (Japan; Yen, ...)
   hi     for Hindi
This kind of convention can solve the known issues of using
"internationl calling code".

I wish to see OO.o to use this convention.



  The Free Standards Group's OpenI18N Locale Name Guideline
  ISO language codes
  ISO territory codes
Comment 2 arthit 2003-04-23 09:24:24 UTC
Example of issue, from Macedonian localization project.
( Zlatko Trajceski <> )

> We also have a small problem - in our internal build
> I chose the number 
> 38 to be our localization number because of the
> telephone code of 
> Macedonia - 389, but I know that also other ex
> Yugoslav countries have 
> telephone codes starting with 38. Can I have 3 digit
> localization 
> number, if not any other solution - can we stick
> with or we have to use 
> some other number?
> Do I have to submit a patch adding a number XX as a
> Macedonian 
> localization or I only have to send you a file with
> translation?

Actually, the above issue may be solved by allow 3-digits code.
But other issues will still remains.

Aiming OO.o to be multi-lingual office suite for the world,
the locale identifier system of OO.o should be flexible enough
to handles "cultural deversity" :)
Comment 3 Dieter.Loeschky 2003-04-23 12:35:46 UTC
DL->ER: Could you please takeover?
Comment 4 Dieter.Loeschky 2003-04-23 15:35:56 UTC
Comment 5 simonbr 2003-04-23 19:20:24 UTC
Hi all, I have more than once wondered why this telephone code is 
used, and why it is apparently so difficult to change this. Does 
anyone have an explanation?
Comment 6 pillai.shikha 2003-04-24 07:29:16 UTC
Hi all,
Indian ISD code is 91 - we are using this identifier for Hindi 
localized version, since Hindi is the national language. However, for 
all other 17 official Indian languages, we definitely need some other 
method to determine the locale identifier. The xx_YY or xx convention 
may be more appropriate for us - Since our ISD code is only 2 digits, 
using 3 digits would mean a different definition for the identifier. 
Comment 7 ooo 2003-04-24 11:48:56 UTC
@Simon: Never ask why ;-)
This is simply a legacy, and yes, it was a bad idea to choose
telephone codes from the very beginning, I don't even know the reason
why it was done (maybe because a certain company used it for similar
purposes? at least they did in another well known product). And yes,
it's even worse that they're still used. The only difficulty I see is
that a change affects quite some places, resource manager, build
environment, setup, runtime files, L10N framework, maybe also
translation tools and databases. Not real obstacles, only that it must
be coordinated.
Comment 8 ooo 2003-04-24 11:53:17 UTC
This is something for your group. Change is on your ToDo list, I
presume, but apparently there is no issue assigned yet.
Comment 9 nils.fuhrmann 2003-04-24 14:56:05 UTC
We have this on our list for 2.0. We have currently detected most of
the code which has to be changed to fully support representation by
iso codes. This affects the resource system, the localization tools,
creation of installation sets and setup itself, different file formats
like *.lng files ...
Plan is to allign this change with migration to the new help file
format   which is already announced.
I will file several dependent tasks to the different owners after 1.1
Beta 2 is released.
The two diggit telefone code was choosen nearly 15 years ago, so
nothing more then historical reasons.
BTW.: If we change these representations it will also have impact to
all translation teams (because of gsi files).
Comment 10 arthit 2003-04-24 15:03:25 UTC
from Nils comment, about gsi files.

do we need to inform this early to dev@l10n list?
(where most of the translators subscribed to)
Comment 11 maho.nakata 2003-04-25 16:45:04 UTC
Hi, This is Maho.
+1 to use Locale based language identifier.
international calling code is not good as Eike said.
Comment 12 kartik.mistry 2004-04-14 19:54:49 UTC
We Really needs some more code allocated to Indian Languages
cause as Shikha said earlier we had 17 official and many languages that spoken
by people whose population is more than some entire countries population !!

I request to allocate code 93 for Gujarati Language
(91 is for Hindi, 92 for Tamil)

Kartik Mistry
LLG Team
Comment 13 ooomod 2004-04-15 11:20:01 UTC
Is this issue really set for the 2.0?
Indian languages are indeed the urgent part of the issue, but we'll see more
like this (African languages, Native-American languages, etc...)
I believe we may be forced to find a global solution to the problem.

Thanks for submitting.
Comment 14 kartik.mistry 2004-04-21 23:37:00 UTC

We have to wait for the 2.0 for language fixes ! ?
Till We are using code 93 for testing as Pavel Janik Suggested ..

But what to do if we want to distribute our final build ?
among Gujarati People ?

Needs Help...


Comment 15 ooomod 2004-04-22 09:22:56 UTC

could you bring this issue forth to the CC? 
I think it's up to you to decide wwnhat should be done now.

Comment 16 paulbe 2004-04-22 09:53:45 UTC
Isn´t this the same as Issue 8252 ?
"Using ISO 639 and ISO 3166 for language codes"
Comment 17 nils.fuhrmann 2004-05-04 10:26:35 UTC
Ause, here is the next one of these redundant issues for the ISO code changes ;-)
Please update the status in allignment with the ongoing changes within the
corresponding child workspace
Comment 18 hjs 2004-05-05 18:18:22 UTC
looks to me like this is covered by #i8252#

*** This issue has been marked as a duplicate of 8252 ***
Comment 19 hjs 2004-05-05 18:19:45 UTC
please reopen if you feel sothing here is not covered