|
|
|
Updated the link as "Relates to".
Ah, was going to add this bug until I noticed it's already here
And completely agree with the points. Each localisation needs a file (lets say skins/xui/*/locale.xml) to contain locale name "Language (Native Name)", (maybe author too), unit names & date/time formats and other such variables that could be broken out of the shared UI. Finally, SL would be better suited with a global file (skins/xui/global.xml ?), so that things like credits, licence, etc, can be removed from each locale, making updates easier. Added another related bug, the previously mentioned British translation.
I sent this comment to the SLDev list regarding internationalization of SL.
The problem I see is that when the XML structure is changed, the translations would be incomplete, which means that the user might not be able to see new functions or would see strange error messages. I'm not a developer but I'm involved in a lot of internationalization / localization projects such as the GNOME Desktop Environment and Ubuntu Linux. There must be some sort of centralized updates of these XML files to avoid distributing incomplete files. I would propose that someone put together a web service or application that would present the translatable strings to the translator. The translator could then translate whatever strings that are untranslated and then the application would generate new XML files. That would create complete files based on the latest XML structure. I guess that GNU gettext would be suitable for this. Posted this earlier on https://lists.secondlife.com/pipermail/sldev/2008-April/009364.html
Here's a little tool attached that I had lying around somewhere and could adapt. It rips the xui files apart and separates function, skin and language parts as suggested. It scans the skins/xui/en-us for all xml files that contain floaters, panels or menus. Then it filters by attributes, and distributes the elements into 3 different document trees. This is just a proof-of-concept, or a skeleton. It should actually do what is needed for the language part, for skinning the filter probably needs some fine-tuning (in start_element in the handler package). The output is formatted in a patch-friendly format. The resulting folder structure is just a proposal, too: ./xui for the functional part, ./skins/default for the styles, and ./lang/en-us for the text. It can easily be changed. Simply place it in the source tree under the newview folder and run from the command line. (Sorry no Python, my mother tongue is Perl). It doesn't overwrite any existing files. Evaluating as part of the Skinning project
I really recommend to reform the present localization process radically. It is absolutely an old-fashioned. Lots of xml files with the mass of xui elements to be translated. It is very hard to handle them. Why don't you use separate language files including exclusively the language elements? Check Joomla or similar CMS for instance. They make it really smart. Moreover this UTF incompatibilty is also a lack of SL viewer. Is anyone around the LL checking these bug reports?
LL is setting up a so called 'Localization Portal', which is - amongst other things - supposed to provide an easy way to suggest new viewer translations. It was supposed to go live mid January but is postponed due to some bugs. I guess the new date is mid February. Let's cross fingers.
Everyone who'd like to take part in the localization of the viewer, please consider joining the Community Translation Project |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Need for a better mechanism to add new UI translation
I'm sorry for that...