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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
