[Geoserver-devel] General Question about changes in properties files

GeoServer GeoServer Developer
1

Hello List,

I’m a bit confused about several commits on properties files in the past and would like to get feedback for a best practices guide we can properly merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of files if translations already/not exists:

  1. Add new key/values to properties files that ends up in UI
  2. Remove properties
  3. rename property keys

Here is what I’d like to suggest to get a clear workflow for developers and translators:

  1. Developers should only maintain the original source language - in this case English - for properties file name GeoServerApplication.properties. Because of the standard java properties file behavior the keys/values are taken from the origin file, if not exists in the preferred language files, e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no need to copy all (not translated) keys with original language (English) into translation files.

  2. If a Developer removes a key from properties file, all other existing translation properies files should be updated as well by removing the key, otherwise translators maintain these Strings and are properly confused about where to find it in the UI.

  3. IMHO avoid the third scenario, it leads into problems when working with translation management systems/services like transifex and crowdin. But if its required (because of revactorings on the java classes/names/package names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with content about how to’s for developers and how to’s for translators? (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas between properties files of source language and the translated files (missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

2

Hi Frank,

Thanks for summing up the issues. I know when I make an update I usually update all the existing files. Mostly because if a key does not exist does it not result in an exception? This wasn’t the case pre wicket < 1.4 but seemed to be the norm when we upgraded? Or does the property lookup stuff fall back on english somehow?

So just to clarify as to what you are proposing, you are saying for additions don’t update the other (in my case non english) property files? But for renames make sure all are updated?

Regardless, I think definitely this should be thrown in the developer guide. I am not sure if under the programming guide section is the best place… i think this probably deserves it’s own section as a sibling of the programming guide. No strong opinion though.

-Justin

On Mon, Dec 5, 2011 at 1:08 AM, Frank Gasdorf <fgdrf@anonymised.com> wrote:

Hello List,

I’m a bit confused about several commits on properties files in the past and would like to get feedback for a best practices guide we can properly merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of files if translations already/not exists:

  1. Add new key/values to properties files that ends up in UI
  2. Remove properties
  3. rename property keys

Here is what I’d like to suggest to get a clear workflow for developers and translators:

  1. Developers should only maintain the original source language - in this case English - for properties file name GeoServerApplication.properties. Because of the standard java properties file behavior the keys/values are taken from the origin file, if not exists in the preferred language files, e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no need to copy all (not translated) keys with original language (English) into translation files.

  2. If a Developer removes a key from properties file, all other existing translation properies files should be updated as well by removing the key, otherwise translators maintain these Strings and are properly confused about where to find it in the UI.

  3. IMHO avoid the third scenario, it leads into problems when working with translation management systems/services like transifex and crowdin. But if its required (because of revactorings on the java classes/names/package names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with content about how to’s for developers and how to’s for translators? (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas between properties files of source language and the translated files (missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

2011/12/5 Justin Deoliveira <jdeolive@anonymised.com>

Hi Frank,

Thanks for summing up the issues. I know when I make an update I usually update all the existing files. Mostly because if a key does not exist does it not result in an exception? This wasn't the case pre wicket < 1.4 but seemed to be the norm when we upgraded? Or does the property lookup stuff fall back on english somehow?

Agree, thats what I arbitrated working on translations in the past. At
the wicket wiki I found, that it supports this kine of serach
capability, see
https://cwiki.apache.org/WICKET/general-i18n-in-wicket.html#Generali18ninWicket-Resourcesearchpath

So just to clarify as to what you are proposing, you are saying for additions don't update the other (in my case non english) property files? But for renames make sure all are updated?

Thank you for carving this out! That was exactly I was trying to express.

Regardless, I think definitely this should be thrown in the developer guide. I am not sure if under the programming guide section is the best place... i think this probably deserves it's own section as a sibling of the programming guide. No strong opinion though.

Me too, lets get some more feedback on this, the place is not so
important right now...

-Justin

Frank

On Mon, Dec 5, 2011 at 1:08 AM, Frank Gasdorf <fgdrf@anonymised.com> wrote:

Hello List,

I'm a bit confused about several commits on properties files in the past and would like to get feedback for a best practices guide we can properly merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of files if translations already/not exists:

1. Add new key/values to properties files that ends up in UI
2. Remove properties
3. rename property keys

Here is what I'd like to suggest to get a clear workflow for developers and translators:

1. Developers should only maintain the original source language - in this case English - for properties file name GeoServerApplication.properties. Because of the standard java properties file behavior the keys/values are taken from the origin file, if not exists in the preferred language files, e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no need to copy all (not translated) keys with original language (English) into translation files.

2. If a Developer removes a key from properties file, all other existing translation properies files should be updated as well by removing the key, otherwise translators maintain these Strings and are properly confused about where to find it in the UI.

3. IMHO avoid the third scenario, it leads into problems when working with translation management systems/services like transifex and crowdin. But if its required (because of revactorings on the java classes/names/package names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with content about how to's for developers and how to's for translators? (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas between properties files of source language and the translated files (missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

Thanks Frank this is really helpful.

On Mon, Dec 5, 2011 at 4:12 PM, Frank Gasdorf
<fgdrf@anonymised.com> wrote:

2011/12/5 Justin Deoliveira <jdeolive@anonymised.com>

Hi Frank,

Thanks for summing up the issues. I know when I make an update I usually update all the existing files. Mostly because if a key does not exist does it not result in an exception? This wasn't the case pre wicket < 1.4 but seemed to be the norm when we upgraded? Or does the property lookup stuff fall back on english somehow?

I guess he means edit only the default language (the one with no _XX
suffix). If you want to add a translation (for example, I use to edit
the default language one and the _es one) then do it only if you know
what you're doing, but not copying just the english string to another
language file. That's because people used to just copy the english
string and append "(ES)" for example, which makes it harder for tools
to recognize which translations are missing?

Cheers,
Gabriel

5

2011/12/5 Gabriel Roldan <groldan@anonymised.com>:

Thanks Frank this is really helpful.

On Mon, Dec 5, 2011 at 4:12 PM, Frank Gasdorf
<fgdrf@anonymised.com> wrote:

2011/12/5 Justin Deoliveira <jdeolive@anonymised.com>

Hi Frank,

Thanks for summing up the issues. I know when I make an update I usually update all the existing files. Mostly because if a key does not exist does it not result in an exception? This wasn't the case pre wicket < 1.4 but seemed to be the norm when we upgraded? Or does the property lookup stuff fall back on english somehow?

I guess he means edit only the default language (the one with no _XX
suffix). If you want to add a translation (for example, I use to edit
the default language one and the _es one) then do it only if you know
what you're doing, but not copying just the english string to another
language file.

Absolutely right! I just took it as read that the default language is
English and that there are no properties files with "_en" suffix..
Thanks for clarification!!
I agree, into the other language files should only translated phrases.
But there could be a reason for it - the English phrase can't be
translated or the terminology is kind of standard (e.g. like Tile).

That's because people used to just copy the english
string and append "(ES)" for example, which makes it harder for tools
to recognize which translations are missing?

That's awful for translations teams, they have the impression
everything is completed (100% because all properties are in the
properties files - origin as well as language specific). Except the
reason mentioned above - this is the decision of the native
speakers/translators which phrases to copy and which to translate ...

Cheers,
Gabriel

Cheers
-Frank

6

Hey Frank, I’m really excited you’re working on this. Making translation easier for people is something I’ve always wanted to do, but I unfortunately don’t know any other languages so there’s not much I can do to help and improve the process.

http://docs.geoserver.org/latest/en/user/introduction/gettinginvolved.html#translation

What do you thing about a new sub-page down under Programming-Guide with content about how to’s for developers and how to’s for > translators? (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

I think more documentation would be great. I’d actually like to see it directly in the user’s guide, where we may get more eyeballs. Like under http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html as that has a mention of translation. It’d be really good to have the whole localization process documented - I’m happy to help out in any way I can.

Also what’s the deal with transfix vs crowdin? And it looks like there’s also a http://translate.geoserver.1os.su/ mirror of the crowdin? If you want I can help direct a translate.geoserver.org to the site you want.

2.x is still behind the 1.x series on translations - I think we had 7 or 8. But if we can get the process figured out to be relatively easy and well documented I think we could get at least double that number. And looks like you’ve got a much better process going.

best regards,

Chris

On Mon, Dec 5, 2011 at 4:08 AM, Frank Gasdorf <fgdrf@anonymised.com> wrote:

Hello List,

I’m a bit confused about several commits on properties files in the past and would like to get feedback for a best practices guide we can properly merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of files if translations already/not exists:

  1. Add new key/values to properties files that ends up in UI
  2. Remove properties
  3. rename property keys

Here is what I’d like to suggest to get a clear workflow for developers and translators:

  1. Developers should only maintain the original source language - in this case English - for properties file name GeoServerApplication.properties. Because of the standard java properties file behavior the keys/values are taken from the origin file, if not exists in the preferred language files, e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no need to copy all (not translated) keys with original language (English) into translation files.

  2. If a Developer removes a key from properties file, all other existing translation properies files should be updated as well by removing the key, otherwise translators maintain these Strings and are properly confused about where to find it in the UI.

  3. IMHO avoid the third scenario, it leads into problems when working with translation management systems/services like transifex and crowdin. But if its required (because of revactorings on the java classes/names/package names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with content about how to’s for developers and how to’s for translators? (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas between properties files of source language and the translated files (missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

Yup, great stuff, and actually i am running into this question again, and not sure what the resolution was for this. I am creating a new page in the ui, and adding some i18n keys. What should I do in the non english versions? Simply keep them as are and do not update them?

On Thu, Dec 15, 2011 at 4:20 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Hey Frank, I’m really excited you’re working on this. Making translation easier for people is something I’ve always wanted to do, but I unfortunately don’t know any other languages so there’s not much I can do to help and improve the process.

http://docs.geoserver.org/latest/en/user/introduction/gettinginvolved.html#translation

What do you thing about a new sub-page down under Programming-Guide with content about how to’s for developers and how to’s for > translators? (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

I think more documentation would be great. I’d actually like to see it directly in the user’s guide, where we may get more eyeballs. Like under http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html as that has a mention of translation. It’d be really good to have the whole localization process documented - I’m happy to help out in any way I can.

Also what’s the deal with transfix vs crowdin? And it looks like there’s also a http://translate.geoserver.1os.su/ mirror of the crowdin? If you want I can help direct a translate.geoserver.org to the site you want.

2.x is still behind the 1.x series on translations - I think we had 7 or 8. But if we can get the process figured out to be relatively easy and well documented I think we could get at least double that number. And looks like you’ve got a much better process going.

best regards,

Chris

On Mon, Dec 5, 2011 at 4:08 AM, Frank Gasdorf <fgdrf@anonymised.com> wrote:

Hello List,

I’m a bit confused about several commits on properties files in the past and would like to get feedback for a best practices guide we can properly merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of files if translations already/not exists:

  1. Add new key/values to properties files that ends up in UI
  2. Remove properties
  3. rename property keys

Here is what I’d like to suggest to get a clear workflow for developers and translators:

  1. Developers should only maintain the original source language - in this case English - for properties file name GeoServerApplication.properties. Because of the standard java properties file behavior the keys/values are taken from the origin file, if not exists in the preferred language files, e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no need to copy all (not translated) keys with original language (English) into translation files.

  2. If a Developer removes a key from properties file, all other existing translation properies files should be updated as well by removing the key, otherwise translators maintain these Strings and are properly confused about where to find it in the UI.

  3. IMHO avoid the third scenario, it leads into problems when working with translation management systems/services like transifex and crowdin. But if its required (because of revactorings on the java classes/names/package names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with content about how to’s for developers and how to’s for translators? (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas between properties files of source language and the translated files (missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

8

On Thu, Dec 15, 2011 at 1:47 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yup, great stuff, and actually i am running into this question again, and
not sure what the resolution was for this. I am creating a new page in the
ui, and adding some i18n keys. What should I do in the non english versions?
Simply keep them as are and do not update them?

Almost.
For any _added_ resource key, do nothing on the translations.
For any changed or removed resource key, _remove_ it on the translations.

That's the only way translators can know what needs to be translated
with the help of the current tools I guess.

2c
Gabriel

9

Justin, sorry for the late response. Go ahead and just commit the i18n
keys in the origin properties file (and do not add these in the
translation files with _xx suffixes).

BTW, what is the final release day? I ask, because I'd like to make
sure, that all properties are translated (into German). Feel free to
add all the required properties, but give me and the whole translation
team just a day to complete before shoot out the 2.1.3 release. Thanks
a lot.

Cheers,
Frank

2011/12/15 Justin Deoliveira <jdeolive@anonymised.com>:

Yup, great stuff, and actually i am running into this question again, and
not sure what the resolution was for this. I am creating a new page in the
ui, and adding some i18n keys. What should I do in the non english versions?
Simply keep them as are and do not update them?

On Thu, Dec 15, 2011 at 4:20 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Hey Frank, I'm _really_ excited you're working on this. Making
translation easier for people is something I've always wanted to do, but I
unfortunately don't know any other languages so there's not much I can do to
help and improve the process.

http://docs.geoserver.org/latest/en/user/introduction/gettinginvolved.html#translation

> What do you thing about a new sub-page down under Programming-Guide with
> content about how to's for developers and how to's for > translators?
> (http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

I think more documentation would be great. I'd actually like to see it
directly in the user's guide, where we may get more eyeballs. Like
under http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html
as that has a mention of translation. It'd be really good to have the whole
localization process documented - I'm happy to help out in any way I can.

Also what's the deal with transfix vs crowdin? And it looks like there's
also a http://translate.geoserver.1os.su/ mirror of the crowdin? If you
want I can help direct a translate.geoserver.org to the site you want.

2.x is still behind the 1.x series on translations - I think we had 7 or
8. But if we can get the process figured out to be relatively easy and well
documented I think we could get at least double that number. And looks like
you've got a much better process going.

best regards,

Chris

On Mon, Dec 5, 2011 at 4:08 AM, Frank Gasdorf
<fgdrf@anonymised.com> wrote:

Hello List,

I'm a bit confused about several commits on properties files in the past
and would like to get feedback for a best practices guide we can properly
merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of
files if translations already/not exists:

1. Add new key/values to properties files that ends up in UI
2. Remove properties
3. rename property keys

Here is what I'd like to suggest to get a clear workflow for developers
and translators:

1. Developers should only maintain the original source language - in this
case English - for properties file name GeoServerApplication.properties.
Because of the standard java properties file behavior the keys/values are
taken from the origin file, if not exists in the preferred language files,
e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no
need to copy all (not translated) keys with original language (English) into
translation files.

2. If a Developer removes a key from properties file, all other existing
translation properies files should be updated as well by removing the key,
otherwise translators maintain these Strings and are properly confused about
where to find it in the UI.

3. IMHO avoid the third scenario, it leads into problems when working
with translation management systems/services like transifex and crowdin. But
if its required (because of revactorings on the java classes/names/package
names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with
content about how to's for developers and how to's for translators?
(http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas
between properties files of source language and the translated files
(missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

10

Chris, thank you so much for your feedback. documentation is a task
for the holidays :wink: I will start on this and it would be great if you
could review !

In case of the crowdin project you mentioned I already contacted the
owner (Lazarev Eugene) and we started to move the languages that
already exists right there to transifex. We haven't finished yet.. but
if its done, I hope he will delete this redundant project as well as I
deleted the project for 2.1.x from crowdin platform a few weeks ago.
Properly you have seen the link to transifex in the description area
of the project. But for now I'm a bit confused about the latest
changes ..(12/15/2011) ... shrug

Cheers
-Frank

2011/12/15 Chris Holmes <cholmes@anonymised.com>:

Hey Frank, I'm _really_ excited you're working on this. Making translation
easier for people is something I've always wanted to do, but I unfortunately
don't know any other languages so there's not much I can do to help and
improve the process.

http://docs.geoserver.org/latest/en/user/introduction/gettinginvolved.html#translation

What do you thing about a new sub-page down under Programming-Guide with
content about how to's for developers and how to's for > translators?
(http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

I think more documentation would be great. I'd actually like to see it
directly in the user's guide, where we may get more eyeballs. Like
under http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html
as that has a mention of translation. It'd be really good to have the whole
localization process documented - I'm happy to help out in any way I can.

Also what's the deal with transfix vs crowdin? And it looks like there's
also a http://translate.geoserver.1os.su/ mirror of the crowdin? If you
want I can help direct a translate.geoserver.org to the site you want.

2.x is still behind the 1.x series on translations - I think we had 7 or 8.
But if we can get the process figured out to be relatively easy and well
documented I think we could get at least double that number. And looks like
you've got a much better process going.

best regards,

Chris

On Mon, Dec 5, 2011 at 4:08 AM, Frank Gasdorf <fgdrf@anonymised.com>
wrote:

Hello List,

I'm a bit confused about several commits on properties files in the past
and would like to get feedback for a best practices guide we can properly
merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of
files if translations already/not exists:

1. Add new key/values to properties files that ends up in UI
2. Remove properties
3. rename property keys

Here is what I'd like to suggest to get a clear workflow for developers
and translators:

1. Developers should only maintain the original source language - in this
case English - for properties file name GeoServerApplication.properties.
Because of the standard java properties file behavior the keys/values are
taken from the origin file, if not exists in the preferred language files,
e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no
need to copy all (not translated) keys with original language (English) into
translation files.

2. If a Developer removes a key from properties file, all other existing
translation properies files should be updated as well by removing the key,
otherwise translators maintain these Strings and are properly confused about
where to find it in the UI.

3. IMHO avoid the third scenario, it leads into problems when working with
translation management systems/services like transifex and crowdin. But if
its required (because of revactorings on the java classes/names/package
names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with
content about how to's for developers and how to's for translators?
(http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas
between properties files of source language and the translated files
(missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

11

On Thu, Dec 15, 2011 at 8:56 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

On Thu, Dec 15, 2011 at 1:47 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yup, great stuff, and actually i am running into this question again, and
not sure what the resolution was for this. I am creating a new page in the
ui, and adding some i18n keys. What should I do in the non english versions?
Simply keep them as are and do not update them?

Almost.
For any added resource key, do nothing on the translations.
For any changed or removed resource key, remove it on the translations.

That’s the only way translators can know what needs to be translated
with the help of the current tools I guess.

Cool, makes sense, will do. And actually i did some testing with missing keys and indeed it only fails for the english version as it is the default. Things work fine if a key is missing from the desired language, but exists in the english version. So I guess this strategy would fall down if someone did this for a particular language, and left the primary file untouched.

2c
Gabriel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

12

No problem Frank, this is development work that is going on on trunk… not something i am going to commit before the release or anything. As for the release I hope to probably do the testing, etc… today and ideally push it out early tomorrow my time (GMT-7). Does that work for you?

On Fri, Dec 16, 2011 at 1:45 AM, Frank Gasdorf <fgdrf@anonymised.com> wrote:

Justin, sorry for the late response. Go ahead and just commit the i18n
keys in the origin properties file (and do not add these in the
translation files with _xx suffixes).

BTW, what is the final release day? I ask, because I’d like to make
sure, that all properties are translated (into German). Feel free to
add all the required properties, but give me and the whole translation
team just a day to complete before shoot out the 2.1.3 release. Thanks
a lot.

Cheers,
Frank

2011/12/15 Justin Deoliveira <jdeolive@anonymised.com>:

Yup, great stuff, and actually i am running into this question again, and
not sure what the resolution was for this. I am creating a new page in the
ui, and adding some i18n keys. What should I do in the non english versions?
Simply keep them as are and do not update them?

On Thu, Dec 15, 2011 at 4:20 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Hey Frank, I’m really excited you’re working on this. Making
translation easier for people is something I’ve always wanted to do, but I
unfortunately don’t know any other languages so there’s not much I can do to
help and improve the process.

http://docs.geoserver.org/latest/en/user/introduction/gettinginvolved.html#translation

What do you thing about a new sub-page down under Programming-Guide with
content about how to’s for developers and how to’s for > translators?
(http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

I think more documentation would be great. I’d actually like to see it
directly in the user’s guide, where we may get more eyeballs. Like
under http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html
as that has a mention of translation. It’d be really good to have the whole
localization process documented - I’m happy to help out in any way I can.

Also what’s the deal with transfix vs crowdin? And it looks like there’s
also a http://translate.geoserver.1os.su/ mirror of the crowdin? If you
want I can help direct a translate.geoserver.org to the site you want.

2.x is still behind the 1.x series on translations - I think we had 7 or
8. But if we can get the process figured out to be relatively easy and well
documented I think we could get at least double that number. And looks like
you’ve got a much better process going.

best regards,

Chris

On Mon, Dec 5, 2011 at 4:08 AM, Frank Gasdorf
<fgdrf@anonymised.com> wrote:

Hello List,

I’m a bit confused about several commits on properties files in the past
and would like to get feedback for a best practices guide we can properly
merge into the developer guide.
IMHO there are 3 major change types on how to work with these kind of
files if translations already/not exists:

  1. Add new key/values to properties files that ends up in UI
  2. Remove properties
  3. rename property keys

Here is what I’d like to suggest to get a clear workflow for developers
and translators:

  1. Developers should only maintain the original source language - in this
    case English - for properties file name GeoServerApplication.properties.
    Because of the standard java properties file behavior the keys/values are
    taken from the origin file, if not exists in the preferred language files,
    e.g. GeoServerApplication_es.properties for Spanish. Therefor there is no
    need to copy all (not translated) keys with original language (English) into
    translation files.

  2. If a Developer removes a key from properties file, all other existing
    translation properies files should be updated as well by removing the key,
    otherwise translators maintain these Strings and are properly confused about
    where to find it in the UI.

  3. IMHO avoid the third scenario, it leads into problems when working
    with translation management systems/services like transifex and crowdin. But
    if its required (because of revactorings on the java classes/names/package
    names) then all existing properties files should maintained as well.

What do you thing about a new sub-page down under Programming-Guide with
content about how to’s for developers and how to’s for translators?
(http://docs.geoserver.org/latest/en/developer/programming-guide/index.html)

And last but not least, do you know a handy tool how to show deltas
between properties files of source language and the translated files
(missing keys, keys that do not exists in origin).

Feedback is warmly welcome!

Cheers
-Frank

All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.