I have finished the localization (in greek) for the newest version of OWB, but in the catalog description file there is a part which strongly mentions to convert the below strings in UTF-8 (for the context menus).
How you can do that, when you create a new catalog? Although everything is working fine, the context menus appear empty (no characters).
Will I need a UTF-8 supported text editor for that, or I can fix that via FlexCat (I'm not completely sure about that)?
To Be A True Adventurer, You Ought To Play Real Text Adventures
Never had such problem when translating in my language, but for what i've understand it appear empty when a string is not availible or cannot be see by the program.. aniway did you got this UTF8 alert during compiling with Flexcat right ?
If yes, can you post the message/error here ?
Aniway for any UTF8 project you might try to work "side by side" with NoWinED
Well the string is available and translated of course, but bear in mind that italian uses latin characters, but greeks no. About FlexCat, no, it didn't give me an alert, it compiles the catalog without any problem.
I will try NoWinED to see.
To Be A True Adventurer, You Ought To Play Real Text Adventures
i think you can simply enter escape sequences for unicode. this should be much better readable and maintainable. for example the german "ü" should result "\xc3\xbc"
on the os4 version unfortunately the utf8 "ü" in the catalog string results in the string not to be rendered... roman needs to check this. no answer yet, though.
I have finished the localization (in greek) for the newest version of OWB, but in the catalog description file there is a part which strongly mentions to convert the below strings in UTF-8 (for the context menus).
That sounds horribly non-standard. Catalog files are supposed to be in whichever 8-bit character set is specified in the header of the file. I'd be surprised if using UTF-8 for certain strings works at all, as locale.library may do some conversion of the strings when the catalog is loaded.
I guess Roman might have an answer to this. As far as I remember this problem was also exactly the same with the first MUI-OWB port for AmigaOS 4.1 as well.
To Be A True Adventurer, You Ought To Play Real Text Adventures
Is there any form of existing "UTF8" header for catalogs?
When I begin expanding beyond code into having Japanese strings I will be needing to deal with escape sequencing *everything*.
There will also be some mixed strings due to that Japanese requires English remain a "side by side"...with the option of any "extended roman" characters are also to be available.
as for right now I am trying to work out some form of comrpessed phonetic format database to match off with the Japanese symbols so that I can properly list the relevant Kanji for any given translation options.
I will also need to reconsider how to use the Jim Breen dictionary database for translation purposes as well.
It looks like OWB is using mixed charsets inside the catalog file. Only MSG_LOCALIZED_XXX should be in UTF-8 and the codeset of the catalog should not be set to UTF-8.
You could try your original translation and replace only the MSG_LOCALIZED_XXX strings with the UTF-8 ones. But I don't know what the locale.library will do.
Is there any form of existing "UTF8" header for catalogs?
Codeset 106 is UTF-8.
It doesn't matter which charset was used for creating a catalog, locale.library converts the strings into the encoding you select with OC_WantedCodeset (default: locale prefs selected ILocale->OpenLocale(NULL)->loc_CodeSet).
For example if Odyssey needs UTF-8 strings it has to use ILocale->OpenCatalog("Odyssey.catalog", OC_WantedCodeSet, 106, ...) to open it's catalogs. The translators must not change anything, they can still use for example ISO-8859-15 (Codeset 111) when creating their translations.
Quote:
When I begin expanding beyond code into having Japanese strings I will be needing to deal with escape sequencing *everything*.
AmigaOS 4.x only supports 8 bit charsets (the ones in LOCALE:Charsets and ISO-8859-1) and UTF-8 (Codeset 106) in locale.library, keymap.library, etc., but no multi byte charsets like Japanese ones, therefore you have to use UTF-8.