Current OpenOffice.org 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,
uses:

    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
language.

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.

e.g.

   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.

----

References:

  The Free Standards Group's OpenI18N Locale Name Guideline
  http://www.li18nux.org/localenameguide/
  
  ISO language codes
  http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt
  
  ISO territory codes
  http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt
  

Example of issue, from Macedonian localization project.
( Zlatko Trajceski <zlat@bagra.net.mk> )

> 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" :)

DL->ER: Could you please takeover?

.

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?

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. 

@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.

Nils,
This is something for your group. Change is on your ToDo list, I
presume, but apparently there is no issue assigned yet.

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).

from Nils comment, about gsi files.

do we need to inform this early to dev@l10n list?
(where most of the translators subscribed to)

Hi, This is Maho.
+1 to use Locale based language identifier.
international calling code is not good as Eike said.

hi,
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
Magnet

kartik_mistry@linux.net

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.

Yeh,

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...

Kartik 
kartik_mistry@linux.net

Pavel,

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

Charles.

Isn´t this the same as Issue 8252 ?
"Using ISO 639 and ISO 3166 for language codes"

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

looks to me like this is covered by #i8252#


*** This issue has been marked as a duplicate of 8252 ***

please reopen if you feel sothing here is not covered