[Geoserver-devel] changes to GeoServerApplication.properties

GeoServer GeoServer Developer
1

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

2

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
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.

3

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

5

I would like to see translating be as simple as creating/editing text files. If people have the _option_ of using an Eclipse plugin to make it easier then that's a plus, but I don't think we should mandate it, as there are many people in our community (I'd imagine) who don't use Eclipse, and I don't think we should make them use it just to add translations.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Arne Kepp wrote:

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

Ok, I think I didn't make my point clear, sorry for the confusion. I'm by _no way_ proposing to drop any ability to edit the properties files with a single text editor. I just thought it _may_ be less burden for anyone developing to just add the resources to the default locale and leave the translators take care of it, instead of having to copy them over the translation when they're not actually translated. Hopefully a tool like RBE makes it very easy to spot out missing resources. But it takes control of the properties file organization, so I won't use it over the default locale in order not to mangle its structure, but I did use it for the _es translation from the start, so that's not a problem.

In the end, my only request is whether we want to require developers to add untranslated strings to translation files other than the default locale or not. Or instead just leave it as it is now (some times they're added, sometimes not, making the life of the translator _perhaps_ more confusing than with a set policy).

Cheers,
Gabriel

Mike Pumphrey wrote:

I would like to see translating be as simple as creating/editing text files. If people have the _option_ of using an Eclipse plugin to make it easier then that's a plus, but I don't think we should mandate it, as there are many people in our community (I'd imagine) who don't use Eclipse, and I don't think we should make them use it just to add translations.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Arne Kepp wrote:

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

One thing that I just ran up against that is relavent here is when code has to call the Localizer directly. IF the key does not exist in a particular locale it will fail.

For instance, when calling the info() method to provide a feedback message. It takes a string only so you have to manually call getLocalizer().get(key,component) to get the i18nized message. Although I admit, there might be a nicer way around this. If not this represents a problem with leaving keys off of any translations.

Gabriel Roldan wrote:

Ok, I think I didn't make my point clear, sorry for the confusion. I'm by _no way_ proposing to drop any ability to edit the properties files with a single text editor. I just thought it _may_ be less burden for anyone developing to just add the resources to the default locale and leave the translators take care of it, instead of having to copy them over the translation when they're not actually translated. Hopefully a tool like RBE makes it very easy to spot out missing resources. But it takes control of the properties file organization, so I won't use it over the default locale in order not to mangle its structure, but I did use it for the _es translation from the start, so that's not a problem.

In the end, my only request is whether we want to require developers to add untranslated strings to translation files other than the default locale or not. Or instead just leave it as it is now (some times they're added, sometimes not, making the life of the translator _perhaps_ more confusing than with a set policy).

Cheers,
Gabriel

Mike Pumphrey wrote:

I would like to see translating be as simple as creating/editing text files. If people have the _option_ of using an Eclipse plugin to make it easier then that's a plus, but I don't think we should mandate it, as there are many people in our community (I'd imagine) who don't use Eclipse, and I don't think we should make them use it just to add translations.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Arne Kepp wrote:

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
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

Sorry, reading the email again, I realize I got caught up in the RBE / Eclipse part of the discussion:

When I started this, at least 30% of the strings in the application were hardcoded in English. I made complete templates with the (DE) prefix in order to spot all the places where the strings were not read from resources at all (-> they would be missing the (DE) prefix in the UI).

The complete templates and (DE) prefixing was not meant as an example for future i18n work. So the answer to your original question is no, I did not intend that you would have to add strings to all the translations. That said, we will need at least one "complete" translation, to flush out when people mess up and commit hardcoded strings.

The other important thing I did was to list all the strings in the default translation in an orderly manner. So that if the default file is expanded, one only needs to look at the default and the translation side by side to spot where strings are missing, without installing Eclipse.

This is the ability that I'm afraid we will lose with tools like RBE. Do we?

-Arne

Gabriel Roldan wrote:

Ok, I think I didn't make my point clear, sorry for the confusion. I'm by _no way_ proposing to drop any ability to edit the properties files with a single text editor. I just thought it _may_ be less burden for anyone developing to just add the resources to the default locale and leave the translators take care of it, instead of having to copy them over the translation when they're not actually translated. Hopefully a tool like RBE makes it very easy to spot out missing resources. But it takes control of the properties file organization, so I won't use it over the default locale in order not to mangle its structure, but I did use it for the _es translation from the start, so that's not a problem.

In the end, my only request is whether we want to require developers to add untranslated strings to translation files other than the default locale or not. Or instead just leave it as it is now (some times they're added, sometimes not, making the life of the translator _perhaps_ more confusing than with a set policy).

Cheers,
Gabriel

Mike Pumphrey wrote:

I would like to see translating be as simple as creating/editing text files. If people have the _option_ of using an Eclipse plugin to make it easier then that's a plus, but I don't think we should mandate it, as there are many people in our community (I'd imagine) who don't use Eclipse, and I don't think we should make them use it just to add translations.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Arne Kepp wrote:

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

9

Arne Kepp wrote:

Sorry, reading the email again, I realize I got caught up in the RBE / Eclipse part of the discussion:

When I started this, at least 30% of the strings in the application were hardcoded in English. I made complete templates with the (DE) prefix in order to spot all the places where the strings were not read from resources at all (-> they would be missing the (DE) prefix in the UI).

sure, that makes sense.

The complete templates and (DE) prefixing was not meant as an example for future i18n work. So the answer to your original question is no, I did not intend that you would have to add strings to all the translations. That said, we will need at least one "complete" translation, to flush out when people mess up and commit hardcoded strings.

ok, we can take the spanish one as the "complete" one. I already spotted some hardcoded strings that still need to be i18n'ized and am meaning to keep it in sync.

The other important thing I did was to list all the strings in the default translation in an orderly manner. So that if the default file is expanded, one only needs to look at the default and the translation side by side to spot where strings are missing, without installing Eclipse.

point taken. Maybe we can come up with a bash script that reports what the missing resources are?

This is the ability that I'm afraid we will lose with tools like RBE. Do we?

Yes, we would. It doesn't seem to be a perfect approach. Another concern wrt i18n is no longer used resources. Ideally we should also keep track of non used resources so the bundle is not incrementally filled with them. That and modifications that might imply the translation needs to be modified too. Hopefully it's not that a big concern and tending to settle down as the UI stabilizes.

So if I have to conclude, I would say:
- let each translator choose the procedure he feels better about, as long as: the default locale gets not mangled, so that's the one for which svn history matters.
- A script to spot out the missing translations would be helpful.
- When adding a new resource to the default locale do not add it to a translation at least you're actually translating
- when no longer using a resource take the time to remove it from the default and all the translations?
- when modifying a resource key modify it also on the translations
- when modifying a resource value delete it from the translations?

That's just a proposal, may be too bothering. What do you think?

Cheers,
Gabriel

-Arne

Gabriel Roldan wrote:

Ok, I think I didn't make my point clear, sorry for the confusion. I'm by _no way_ proposing to drop any ability to edit the properties files with a single text editor. I just thought it _may_ be less burden for anyone developing to just add the resources to the default locale and leave the translators take care of it, instead of having to copy them over the translation when they're not actually translated. Hopefully a tool like RBE makes it very easy to spot out missing resources. But it takes control of the properties file organization, so I won't use it over the default locale in order not to mangle its structure, but I did use it for the _es translation from the start, so that's not a problem.

In the end, my only request is whether we want to require developers to add untranslated strings to translation files other than the default locale or not. Or instead just leave it as it is now (some times they're added, sometimes not, making the life of the translator _perhaps_ more confusing than with a set policy).

Cheers,
Gabriel

Mike Pumphrey wrote:

I would like to see translating be as simple as creating/editing text files. If people have the _option_ of using an Eclipse plugin to make it easier then that's a plus, but I don't think we should mandate it, as there are many people in our community (I'd imagine) who don't use Eclipse, and I don't think we should make them use it just to add translations.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Arne Kepp wrote:

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

10

Gabriel Roldan wrote:

Arne Kepp wrote:

Sorry, reading the email again, I realize I got caught up in the RBE / Eclipse part of the discussion:

When I started this, at least 30% of the strings in the application were hardcoded in English. I made complete templates with the (DE) prefix in order to spot all the places where the strings were not read from resources at all (-> they would be missing the (DE) prefix in the UI).

sure, that makes sense.

The complete templates and (DE) prefixing was not meant as an example for future i18n work. So the answer to your original question is no, I did not intend that you would have to add strings to all the translations. That said, we will need at least one "complete" translation, to flush out when people mess up and commit hardcoded strings.

ok, we can take the spanish one as the "complete" one. I already spotted some hardcoded strings that still need to be i18n'ized and am meaning to keep it in sync.

The other important thing I did was to list all the strings in the default translation in an orderly manner. So that if the default file is expanded, one only needs to look at the default and the translation side by side to spot where strings are missing, without installing Eclipse.

point taken. Maybe we can come up with a bash script that reports what the missing resources are?

This is the ability that I'm afraid we will lose with tools like RBE. Do we?

Yes, we would. It doesn't seem to be a perfect approach. Another concern wrt i18n is no longer used resources. Ideally we should also keep track of non used resources so the bundle is not incrementally filled with them. That and modifications that might imply the translation needs to be modified too. Hopefully it's not that a big concern and tending to settle down as the UI stabilizes.

So if I have to conclude, I would say:
- let each translator choose the procedure he feels better about, as long as: the default locale gets not mangled, so that's the one for which svn history matters.
- A script to spot out the missing translations would be helpful.
- When adding a new resource to the default locale do not add it to a translation at least you're actually translating
- when no longer using a resource take the time to remove it from the default and all the translations?
- when modifying a resource key modify it also on the translations
- when modifying a resource value delete it from the translations?

That's just a proposal, may be too bothering. What do you think?

Cheers,
Gabriel

Sounds good, especially the last three rules. Maybe we can steal a language "nobody will ever use (tm)" and use it to test for hardcoded strings, i.e. automatically copy the default and prefix with something.

Maybe the script can be a community module that we run with maven ? Quickly looked for examples using awk, looks like it'll be easier to do this in Java than in bash.

-Arne

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

11

Justin Deoliveira wrote:

One thing that I just ran up against that is relavent here is when code has to call the Localizer directly. IF the key does not exist in a particular locale it will fail.

For instance, when calling the info() method to provide a feedback message. It takes a string only so you have to manually call getLocalizer().get(key,component) to get the i18nized message. Although I admit, there might be a nicer way around this. If not this represents a problem with leaving keys off of any translations.

ah, interesting... I've been doing it like String.valueOf(new ResourceModel("key", "default"))... would that be one sensible replacement for getLocalizer()? (btw, I didn't know about getLocalizer() so it might be just luck)

Cheers,
Gabriel

Gabriel Roldan wrote:

Ok, I think I didn't make my point clear, sorry for the confusion. I'm by _no way_ proposing to drop any ability to edit the properties files with a single text editor. I just thought it _may_ be less burden for anyone developing to just add the resources to the default locale and leave the translators take care of it, instead of having to copy them over the translation when they're not actually translated. Hopefully a tool like RBE makes it very easy to spot out missing resources. But it takes control of the properties file organization, so I won't use it over the default locale in order not to mangle its structure, but I did use it for the _es translation from the start, so that's not a problem.

In the end, my only request is whether we want to require developers to add untranslated strings to translation files other than the default locale or not. Or instead just leave it as it is now (some times they're added, sometimes not, making the life of the translator _perhaps_ more confusing than with a set policy).

Cheers,
Gabriel

Mike Pumphrey wrote:

I would like to see translating be as simple as creating/editing text files. If people have the _option_ of using an Eclipse plugin to make it easier then that's a plus, but I don't think we should mandate it, as there are many people in our community (I'd imagine) who don't use Eclipse, and I don't think we should make them use it just to add translations.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Arne Kepp wrote:

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

12

Gabriel Roldan wrote:

Justin Deoliveira wrote:

One thing that I just ran up against that is relavent here is when code has to call the Localizer directly. IF the key does not exist in a particular locale it will fail.

For instance, when calling the info() method to provide a feedback message. It takes a string only so you have to manually call getLocalizer().get(key,component) to get the i18nized message. Although I admit, there might be a nicer way around this. If not this represents a problem with leaving keys off of any translations.

ah, interesting... I've been doing it like String.valueOf(new ResourceModel("key", "default"))... would that be one sensible replacement for getLocalizer()? (btw, I didn't know about getLocalizer() so it might be just luck)

Cool, that looks safer cause it handles null right?

Cheers,
Gabriel

Gabriel Roldan wrote:

Ok, I think I didn't make my point clear, sorry for the confusion. I'm by _no way_ proposing to drop any ability to edit the properties files with a single text editor. I just thought it _may_ be less burden for anyone developing to just add the resources to the default locale and leave the translators take care of it, instead of having to copy them over the translation when they're not actually translated. Hopefully a tool like RBE makes it very easy to spot out missing resources. But it takes control of the properties file organization, so I won't use it over the default locale in order not to mangle its structure, but I did use it for the _es translation from the start, so that's not a problem.

In the end, my only request is whether we want to require developers to add untranslated strings to translation files other than the default locale or not. Or instead just leave it as it is now (some times they're added, sometimes not, making the life of the translator _perhaps_ more confusing than with a set policy).

Cheers,
Gabriel

Mike Pumphrey wrote:

I would like to see translating be as simple as creating/editing text files. If people have the _option_ of using an Eclipse plugin to make it easier then that's a plus, but I don't think we should mandate it, as there are many people in our community (I'd imagine) who don't use Eclipse, and I don't think we should make them use it just to add translations.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Arne Kepp wrote:

I'm fine with either making the translation templates, like I started doing, or using an external tool like RBE which (I haven't tried). As long as the translator gets a good overview of what is missing without having to run the application.

That said, I'm not particularly fond of Eclipse dependencies. Do you have to set up the entire environment ? My worry is that we set the bar too high for community contributions, and translations are a great way for people who don't write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.

But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :slight_smile: The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't.

Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier...
The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever.

Cheers,
Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference hence I would like to hear others opinion. WRT to UI i18n resources, when adding new strings I would prefer them to be added to the default properties file but not to the translations, at least you're actually translating. That is, if adding a resource to GeoServerApplication.properties like someText=Some Text, adding someText=(ES) Some Text to GeoServerApplication_es.properties and someText=(DE) Some Text to GeoServerApplication_de.properties, etc. seems counter productive to me. But that's because I prefer to rely on a tool to perform the translation, ResourceBundleEditor, in which I can see at a glance which resources are _missing_. But the above practice would prevent that. Instead, I would have to walk over the whole UI looking for "(ES)...". Well... or rather just watch out the commit logs or grep the GSApp_es.properties itself. So not a big deal, just a personal preference. Others might think it's better the way it's being done now. Those I encourage to try out the ResourceBundleEditor plugin for eclipse if they're doing some translations. You might find it quite useful as I do.
Meanwhile, do you think we could agree on keeping from adding untranslated resources? Or is there any stronger preference on keeping the current practice?

Cheers,
Gabriel

------------------------------------------------------------------------------

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
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.

13

Here is something to try - we bundled up a stand-alone RCP app with just the resource bundle editor in it. What we do for udig is zip up all the properties files; and then ask volunteers to download the both the zip and the program. When they are done a committer can unzip the result and check in any changes.

Instructions:

Direct download (so you can try it out with out eclipse):

Jody

On 13/08/2009, at 1:37 AM, Arne Kepp wrote:

I’m fine with either making the translation templates, like I started
doing, or using an external tool like RBE which (I haven’t tried). As
long as the translator gets a good overview of what is missing without
having to run the application.

That said, I’m not particularly fond of Eclipse dependencies. Do you
have to set up the entire environment ? My worry is that we set the bar
too high for community contributions, and translations are a great way
for people who don’t write code to give back to the project.

-Arne

Gabriel Roldan wrote:

Justin Deoliveira wrote:

Well I guess there is no practice at this point. I just followed what

i saw in the de translation put together by Arne.

But it makes sense that different translators will have different

preferences for how they want things done. I am fine either way…

either leaving the translations untouched and put the burden on the

translator to figure out what they need to translate, or to somehow

mark which strings they need to translate.

Since Arne and yourself are currently the only ones working on

translations i leave it to you guys to debate :slight_smile: The only problem I

see with different translators doing it differently is that it is

hard for someone like myself to remember which translations i need to

update and which I don’t.

Of course. My intent is to get to a concensus. My preference of

leaving untranslated untouched may also alleviate the task for the non

translators. We the translators can as easily use a tool like RBE to

make our lives easier…

The only problem I can see though, is when not adding a i18n resource,

but when modifying it… Perhaps when you modify a resource in the

default locale you can just delete it from the other locales so it’s

evident it needs to be redone for us?

Arne, do you have a preference? I will be totally ok if you don’t want

to go my proposed way because you translate with vim, emacs, whatever.

Cheers,

Gabriel

2c,

-Justin

Gabriel Roldan wrote:

Hi,

I have an thought which I think might be just a personal preference

hence I would like to hear others opinion. WRT to UI i18n resources,

when adding new strings I would prefer them to be added to the

default properties file but not to the translations, at least you’re

actually translating. That is, if adding a resource to

GeoServerApplication.properties like someText=Some Text, adding

someText=(ES) Some Text to GeoServerApplication_es.properties and

someText=(DE) Some Text to GeoServerApplication_de.properties, etc.

seems counter productive to me. But that’s because I prefer to rely

on a tool to perform the translation, ResourceBundleEditor, in which

I can see at a glance which resources are missing. But the above

practice would prevent that. Instead, I would have to walk over the

whole UI looking for “(ES)…”. Well… or rather just watch out the

commit logs or grep the GSApp_es.properties itself. So not a big

deal, just a personal preference. Others might think it’s better the

way it’s being done now. Those I encourage to try out the

ResourceBundleEditor plugin for eclipse if they’re doing some

translations. You might find it quite useful as I do.

Meanwhile, do you think we could agree on keeping from adding

untranslated resources? Or is there any stronger preference on

keeping the current practice?

Cheers,

Gabriel

Let Crystal Reports handle the reporting - Free Crystal Reports 2008

30-Day trial. Simplify your report design, integration and

deployment - and focus on what you do best, core application coding.

Discover what’s new with Crystal Reports now.

http://p.sf.net/sfu/bobj-july

Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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