Enterprise Localization Toolkit can't handle 6 character cultures e.g. zh-CHT

[Fabian Dal Santo]

Apologies for cross-postings...

We have been using the Enterprise Localization Toolkit for a project
and it seems to have a bug. It assumes that all cultures are 5 char
in length e.g. English(Australian) en-AU, but the .NET framework has
some that are actually 6 characters in length, e.g.
Chinese(Traditional) zh-CHT. Since Chinese(Simplified) is zh-CHS, we
can't simply use the truncated version.

I have managed to fix the web app so we can actually populate the
database correctly, but when generating the resource files, the zh-CHT
resource file is, I believe, corrupt. It cannot be viewed correctly
in the resource viewer, whereas all the other files can.

Has anyone else had a similar problem, and been able to fix it?

Fabian

 

[Steven Cheng[MSFT]]

Hi fabiand,


Thank you for using Microsoft Newsgroup Service. Based on your description,
you want to know how to set those culture info's country/region area which
is represented by three letter( such as zh-CHS,zh-CHT) as two letter format
when you are using the Enterprise Locallization toolkit. Please feel free
to post here is my understanding is not quite correct.

As for this problem, I think the two format of the country/region code is
just refer to two different standard of the ISO.
The two letter format such as US, CN(simplified), TW(traditional) is for
the ISO 3166 standard. And as for the culture setting in dotnet Enterprise
localization toolkit, it specify user to use the ISO 3166 for the
country/region partition. Here is the reference in MSDN:

Names follow the RFC 1766 standard in the format
"<languagecode2>-<country/regioncode2>", where <languagecode2> is a
lowercase two-letter code derived from ISO 639-1 and <country/regioncode2>
is an uppercase two-letter code derived from ISO 3166. For example, U.S.
English is "en-US".

Of course, every three letter code can be represented correctly by a two
letter format code without any corruption. For example:
3 letter 2 letter
zh-CHS zh-CN
zh-CHT zh-TW

.....

For more detailed list and information on this, you can visit the relative
references on MSDN library or ISO site, here some of the info I found:

Valid Locale Identifiers in MSDN:
http://msdn.microsoft.com/library/en-us/indexsrv/html/ixuwebqy_7gfn.asp?fram
e=true

ISO 3166 Code lists:
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list
-en1.html


Please check out the above information. Hope they are helpful. If you need
any help , please feel free to let me know.


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Fabian Dal Santo]

Steven,
Thanks for your reply. Yes you pretty much have the idea of my
problem.

Regards the conversion from 3 to 2 letter codes, isn't the zh-TW a
specific code for Chinese(Taiwan) rather than another name for
Chinese(Traditional)? So if we set up everything for zh-TW and not
zh-CHT, if the person using the site was using a child culture of
zh-CHT (but not zh-TW), or zh-CHT itself, then the site would not know
to look for the specific culture of zh-TW? Then it would try to fall
back to zh-CHT, not find anything defined for that, and fall back to
the invariant culture. Am I getting this all confused?

The other problem we have is that the dropdown list that the toolkit
uses to add cultures gets the 3 letter codes, so when it tries to put
zh-CHT or zh-CHS into the database they get truncated to zh-CH (since
the SQL stored procedures truncate them to 5 chars. Yes I could
change the stored procs, but there's other problems related to that).
We could put them in as specific cultures e.g. Taiwan, but then we get
the problem that I described above.

Thanks,
Fabian

 

[Fabian Dal Santo]

Steven,

Thanks for your reply. What you described is a valid workaround, but
still not completely satisfactory. It lowers the maintainablity and
robustness of the site. Let me give you an example with the English
language. We have "en" as the root parent language and then en-US and
en-AU as two of the children languages. These can all be specified as
valid languages in the ELT and all 3 work fine. If a person has
"en-AU" specified as their language, and there is no translation, it
falls back to "en" where (hopefully) there is a tranlation for it.
Similarly for someone using "en-US".

The beauty lies in the fact that the translators can then translate
all the english words in to the "en" language, where the word is the
same both "en-AU" and "en-US", thus saving them having to duplicate
the translations. They then leave the "en-AU" and "en-US"
translations blank. When the ELT searches for the translation for
either of those, it will find none and fall back to the "en" version.
We need only add in "en-AU" and "en-US" translations where there is a
difference, and anyone else using an english language (not AU or US)
will still fall back to "en" and should be able to read it. If we
were to add another English variant, e.g. "en-GB" all the translators
would have to do is add in the words that differ into "en-GB" and
leave the rest of the translations blank, thus saving loads of time.

Without being able to specify "zh-CHT" in the ELT, we have no parent
languge for Chinese(Traditional). The translators will have to
translate every word into "zh-TW", and if we use another
Chinese(Traditional) child language, all those translations will have
to be duplicated again. Also anyone coming in with another child
language of Chinese(Traditional) (not "zh-TW"), will get the invariant
language, English, rather than the parent of Chinese(Traditional),
"zh-CHT", and will not be able to read it. So in fact, being able to
specify "zh-CHT" into the ELT is fairly fundamental.

It appears to me that there is no satisfactory way around this
problem, other than allowing 6 character culture specifiers into the
ELT.

Sorry for the length of the post, but I thought an example would make
it clearer.

Fabian.

 

[Steven Cheng[MSFT]]

Hi fabiand,


Thank you for your response and the detailed description. I've got that
you'd like to specify a "neutral culture" so that if any specify culture's
mathc failed, the neutral parent culture can be used to display content.
Also, I've reviewed the CultureInfo in the MSDN, and found the following
info:

-----------------------
Throughout this topic, the terms "neutral culture" and "specific culture"
are used. A neutral culture is specified by only the two-digit lowercase
culture code. For example, "fr" specifies the neutral culture for French,
and "de" specifies the neutral culture for German. A specific culture is
identified by the culture code followed by the two-digit uppercase
subculture code. For example, "fr-FR" specifies French in France and "fr-CA
specifies French in Canada.

Note There are two culture names that contradict this rule. The cultures
"zh-CHS" (Simplified Chinese) and "zh-CHT" (Traditional Chinese) are
neutral cultures.

-----------------------

It seems that the zh-CHS and zh-CHT are two particular case for the
"neutral culture". And based on your experience, the ELT did have the
limits on the configuration for the two "neutral culture". In addtion,
since the dotnet runtime will fall back to find parent culture resource.
Would you have a try manually put the zh-CHS and zh-CHT's resource in the
proper directory without configure them in the ELT. Anyway, I'll archive
this issue in mind since it due to a limit of the ELT.

If you have any questions or need any further assistance, please feel free
to post here.


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Steven Cheng[MSFT]]

Hi fabiand,


Have you had any progress on this issue or have you resolved the problem?
Please feel free to post here is you need any assistant.



Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)