Think about ease of i18n

[GoogleCodeExporter]

Find out how to easily manage the translation process. If something changes 
to the English file all other files should be updated. But how are we gonna 
inform the translators about it?

Original issue reported on code.google.com by dirkvran...@gmail.com on 9 May 2010 at 4:07

[GoogleCodeExporter]

As the strings file isn't overwhelming (yet?) it's more a version control 
issue, than 
a translation issue, really. The more people doing translations, the greater 
the risk 
of missing translations, and thus a loss of control over the development cycle.

Have been looking into this a little bit, and have not been able to find any 
decent 
i18n management system for android development. There are plenty of resource 
translation systems for java resources and prop files, but I can't find a 
decent one 
to handle xml.

I also get the general feeling that not everyone is happy about how i18n (w/loc 
strings.xml) is implemented in the android skd. I've come across reports that 
there 
seems to be an fc issue occurring when there are inconcistensies (missing 
translations) in the strings-files, for example.

I'll keep looking :)

Original comment by fredrik.nohrborg on 10 May 2010 at 10:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've thought about the i18n process and this is what I came up with:
  * During the development process we will keep a list of all items in the English 
XML file which changed on the InternationalizationChanges page.
  * Before creating a new release I'll send out a mail to all the translators as 
specified on the ReleaseManagement page.

This requries a little more work for the developers but will ease up the 
process of 
i18n a lot I think as you guys do not have to search for which values have 
changed 
or have been added.

Original comment by dirkvran...@gmail.com on 11 May 2010 at 8:25

[GoogleCodeExporter]

Original comment by dirkvran...@gmail.com on 15 Aug 2010 at 1:48

• Changed state: Done