Hi Mike,
I see you added Brazillian Portugese to a recent release of OM, can you tell me how you went about getting the translation done? - Not in terms of finding and/or paying translators, but whether you used any content management software etc
I have to set up agreements for software translation in to spanish, korean , chinese etc so I'm interested in what approach you take with language translation.
cheers
sam
Mike - Only Mortal
The localization is done from the "Localizable.strings" and ".nib" files inside the English.lproj folder.
I e-mailed the strings file along with text copied/pasted from the nib files in text documents, telling the translators to edit the files as UTF-8. You can open a file in TextEdit.app as UTF-8.
The format of the text files is always:
"key" = "translation";
"key" is what the application looks for and "translation" is what gets displayed so, they only edit the "translation" portion of the key/value pair.
Text files are the easiest for people to edit, naturally, but it's important to emphasise saving as UTF-8 so any accented or non-roman characters are preserved.
To read the strings file I just used [NSBundle loacalizedStringForKey:@"key" value:nil table:nil] and paste the nib strings into a copy of the original English nib files which I locate in a directory appropriate for the localization.
You can also read strings files from the Carbon API though it's a little long winded, been C.
It's important that the application treats all 8-bit strings as UTF-8 and processes strings internally as UTF-16. If the app is STL based, wide characters are UTF-32 (wchar_t) in a std::wstring but it's trivial to write conversion routines that go between what the Mac APIs use and what STL and the old wide character C functions use with the "iconv" library (see "man 3 iconv"). Remember to do conditional compilation for Intel and PPC architectures as UTF-16 and UTF-32 are endian specific.
I e-mailed the strings file along with text copied/pasted from the nib files in text documents, telling the translators to edit the files as UTF-8. You can open a file in TextEdit.app as UTF-8.
The format of the text files is always:
"key" = "translation";
"key" is what the application looks for and "translation" is what gets displayed so, they only edit the "translation" portion of the key/value pair.
Text files are the easiest for people to edit, naturally, but it's important to emphasise saving as UTF-8 so any accented or non-roman characters are preserved.
To read the strings file I just used [NSBundle loacalizedStringForKey:@"key" value:nil table:nil] and paste the nib strings into a copy of the original English nib files which I locate in a directory appropriate for the localization.
You can also read strings files from the Carbon API though it's a little long winded, been C.
It's important that the application treats all 8-bit strings as UTF-8 and processes strings internally as UTF-16. If the app is STL based, wide characters are UTF-32 (wchar_t) in a std::wstring but it's trivial to write conversion routines that go between what the Mac APIs use and what STL and the old wide character C functions use with the "iconv" library (see "man 3 iconv"). Remember to do conditional compilation for Intel and PPC architectures as UTF-16 and UTF-32 are endian specific.
Just some more notes...
If the application programmer hasn't been nice to you making translations easier, check out "man strings" which you can use to extract strings inside an executable.
There're also some translation editors on versiontracker that help editing the old ".rsrc" files if the app is an old Carbon app.
If it's PowerPlant based, you can edit the "ppob" files for the developer but you'd need to get hold of "PowerPlant Constructor" which is the UI editor for CodeWarrior legacy apps.
If the application programmer hasn't been nice to you making translations easier, check out "man strings" which you can use to extract strings inside an executable.
There're also some translation editors on versiontracker that help editing the old ".rsrc" files if the app is an old Carbon app.
If it's PowerPlant based, you can edit the "ppob" files for the developer but you'd need to get hold of "PowerPlant Constructor" which is the UI editor for CodeWarrior legacy apps.
thanks Mike, we can definately draw on some methods there in relation to string files; although we also have some java based apps that users download and communicate with our server through a firewall, these might need a little more work, but the guys are on it!
cthanks again
cthanks again
"Liberty, what crimes are committed in your name."