Changes between Version 1 and Version 2 of i18n

Timestamp:

Jul 18, 2007, 5:39:15 AM (17 years ago)

Author:

ticheler

Comment:

--

i18n

@@ -1 +1 @@
 == Translation / localization issues ==
-Some ideas on how translation of the software can be improved in the future. I started some discussion on this topic on the mailinglist (see: http://www.nabble.com/Localization-issues-tf4097440s18419.html ).
+Some ideas on how translation of the software can be improved in the future. I (Jeroen) started some discussion on this topic on the mailinglist (see: http://www.nabble.com/Localization-issues-tf4097440s18419.html ).
 
 '''Our current structure of language files is the following one:'''
@@ -54 +54 @@
 }}}
 
-I think this can have the following advantages:
+This can have the following advantages:
 
  - This has minimal impact on our existing stylesheets that generate the localized output.
  - It is pretty trivial to generate a list of i18n_keys in use in the software.
  - The generated output can be used to highlight missing and obsolete keys in each language file.
- - There is the potential to store all keys and language strings in a database that has a simple translation user interface accessible through the web. Such translation mechanism has already been implemented in GeoNetwork opensource for the non-static strings in the system. It could be setup on the developer website to work as the central translation facility. The static files required for a release can be generated as language packages automatically and be stored in SVN.
+ - There is the potential to store all keys and language strings in a database that has a simple translation user interface accessible through the web. Such translation mechanism has already been implemented in !GeoNetwork opensource for the non-static strings in the system. It could be setup on the developer website to work as the central translation facility. The static files required for a release can be generated as language packages automatically and be stored in SVN.