Open wxtrac opened 15 years ago
As an example try reading this (I'm imagine that you don't read Japanese)
http://www.jcp.or.jp/index.html
If there wasn't an "English" (latin charset) link on the top bar because "English" was written also in Japanese... you'd be totally lost.
I think this happens the other way around in a lot of countries.
Thanks for your time -Martín
We'd need to add a new column to misc/languages/langtabl.txt
containing the language name in this language -- the trouble would be getting contents for it for all the languages, of course. Other than that it looks simple enough to do and I agree that this would be useful. Maybe we could start by adding the names just for some languages and using untranslated names for the rest...
Yes, great idea...
But please also add the "Please choose a language" for each language.
Notice that now langtabl.txt doesn't have any non-ANSI characters. The script can handle UTF8/Unicode files?
Also, a script could generate another h/cpp or something... so the translated languages are in the lib instead of in the *.mo's. It could be unicode-encoded and compiler friendly without problems using something like:
#ifdef _UNICODE
L"\x0041\x0042\x0043"
#else
"ABC"
#endif
(But with the language names. The latter could be downcasted to Latin-1 for non unicode builds?)
Maybe checking for directories with canonical names or something like that (as AddCatalog() does when loading) could be a way to get all the available langs. Could also check if there is at least one *.mo in the folder.
I don't really have an approach on that :P I'm really new to wxLocale and this internationalization stuff.
Regards -Martín
Replying to [comment:3 nitram_cero]:
But please also add the "Please choose a language" for each language.
This looks rather pointless -- in which language would you show this initially?
Besides, I really think that seeing the name of the language should be a pretty strong hint.
Notice that now langtabl.txt doesn't have any non-ANSI characters. The script can handle UTF8/Unicode files?
I don't know, it would need to be tested. Also, we need to transform UTF-8 to C escapes for inclusion into .cpp so we could use this (ugly...) format in the file itself anyhow.
Also, a script could generate another h/cpp or something... so the translated languages are in the lib instead of in the *.mo's.
I don't see the need for another file, the generated strings are already included in locale.cpp and this is quite fine AFAICS.
This looks rather pointless -- in which language would you show this initially? I'd show them in all available translations. I'm thinking that for apps with no more than 10 translations. Obviously for apps with 200 translations this would be prohibitive.
Besides, I really think that seeing the name of the language should be a pretty strong hint. Yes, I agree with you on that. But for 200 translations it could be a little harder to figure out your language from the rest... Maybe if the dialog could have an icon besides the text in english (that defaults to a globe, globemap or something), that would be the most intuitive way to highlight the meaning.
I don't see the need for another file, the generated strings are already included in locale.cpp and this is quite fine AFAICS. Oh, I didn't knew. Having it in locale.cpp would be best.
Regards -Martín
Regarding the source of translated names: ICU or iso-codes. The latter consists of a) XML file with language codes and English names and b) Gettext catalogs with translations. But the license is LGPL (whatever that's supposed to mean on data files...), which is incompatible.
But I would say that if you are translating your app into different languages (and it doesn't make sense to show this dialog for languages that you don't translate your app to), then you can just as well include a "TRANSLATE_THIS_AS_YOUR_LANGUAGE_NAME" string and ask your translators to provide it.
In other words: fixing this in an app (for a bunch of languages) is much, much easier than doing it in the library (for "all" languages).
Or you can use English names (wx ships them), ship iso-codes MO files with your app and just add a few AddCatalog
calls to your app to load them. We could do this one in wx itself too, but these catalogs are quite large and imposing that penalty on all apps (even these without language chooser) doesn't sound like good idea.
@vaclavslavik, Are you saying it is not a good idea to have this implemented in wx itself?
But on top of that - a) we already have such dialog in the internat sample and b) the i18n is retrieving translation based on the default locale used by OS (IIUC).
Issue migrated from trac ticket # 10961
component: translations | priority: normal | keywords: i18n internationalization translation string array choose language locale wxlocale
2009-07-03 22:33:42: nitram_cero created the issue
IT would be nice to be able to get an array with all the available languages in their respective language (i.e. English, Español, Français, ...) and their associated language IDs from a wxLocale function.
This array could be fed to a wxSingleChoiceDialog, and have an easily made and totally internationalized language selection dialog.
Also it would be cool to have "Please choose a language." translated in each language, and then load them for each translation available.
You must think that not everybody knows English, so having a dialog that says "Choose your language: English|Spanish|French|Japanese" Is totally useless if you don't even know the translated word for your own language name (specially for non latin charset langs, like Japanese).
So a multilingual dialog (for all available languages) like:
Would be awesome.
Regards -Martín