The policy we've been following so far was that it was mandatory to create each property in each language file -- even if the text was in English. The translators would then scan the text for English phrases and translate them. I guess this could be tough for languages with many common words with English, like German. In any case, the scanning can't not be automated (in the absence of AI, I mean).
i18nEdit expects untranslated texts to be left nonexisting or blank. Otherwise it will assume that the entered text are an OK translation and they won't be visited using F2 in "Translator" mode.
So, I would propose to write our ResourceBundle subclass that will provide the English strings for any resources missing in the per-language property file.
Then, as you said, we should only check that the files for the other locales have not invented new keys (which would probably indicate a key misspelling) and, where possible, check the English files for completeness.
This completeness test is pretty trivial, for the beans, but I'm not 100% sure we should do it. I would like to make it trivial to create a bean without any description text altogether -- just display the bean class name as the component title, property name in front of each property editor, etc. Maybe we could just exclude beans with a description containing (Alfa), or (Beta) or (Experimental) from the test.
Comments?
-- Salut,
Jordi.
En/na Sebastian Bazley ha escrit:
OK.
Since Java uses the default property file if it can't find the locale-specific key, I was going to suggest dropping the check that the keys in all the files agree, and just checking that there weren't any "extra" keys in the de/no/ja files. But using i18nEdit makes it easy to add the same key and value to all the files at once, so we might as well keep the files up to date.
It might be useful at some stage to write a test to trawl the Java files looking for key strings and check that they all appear in a property file somewhere. Could perhaps use/extend one of the code checkers such as PMD for this, I suppose - if there isn't already a tool to do it. It ought to be easier to check the Bean files, as the key names are automatically derived.
S.
----- Original Message ----- From: "Jordi Salvat i Alabart" <[EMAIL PROTECTED]>
To: "JMeter Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, January 18, 2004 8:10 PM
Subject: Re: Bean Properties
I'm for a double-check. Extending the test doesn't look trivial, but not too difficult either. One of the nice things about i18nEdit (according to its own documentation) is that it still allows editing the property files with whatever editor you choose, so we should not rely on everyone using it.
-- Salut,
Jordi.
En/na Sebastian Bazley ha escrit:
OK by me.
Just need to decide whether to extend the existing JUnit test to cover all the property files, or drop it and rely on the tool
to
find any omissions.
S.
----- Original Message ----- From: "Jordi Salvat i Alabart" <[EMAIL PROTECTED]>
To: "JMeter Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, January 17, 2004 11:35 PM
Subject: Re: Bean Properties
Hi.
i18nEdit is exactly what we need: it handles projects with multiple .properties files very nicely. You just press F2 and it takes you to the next [untranslated] property -- even if it is in a separate file. It also provides the equivalent of diff/patch to handle sending changes and committing them.
So I'll stick to my opinion that it's better to put resources in separate files -- up to one per bean in the TestBeans case.
In which case, we should: - Add i18nEdit's i18nedit.properties and .../*.metaprops files to CVS. - Write some brief documentation on how a translator should use i18nEdit to write translations, and how a committer should merge in submitted translations.
Any arguments against this plan?
-- Salut,
Jordi
En/na Jordi Salvat i Alabart ha escrit:
Been looking at RBManager. If I've understood well, RBManager manages single files (with their translations) only.
Looks like it's not a good idea to have tons of small .properties files scattered all through the src directories -- unless we find some other tool that handles that better.
One single monolithic messages.properties as we have now is awful and inconvenient: programmers writing their own test elements now need to edit that file, and redo their changes on every upgrade... or go their own way. Plus the messages lack context, which makes a correct translation very difficult.
One .properties file per package would not improve things much, because we often classes in the same package defined in separate source directories (e.g. org.apache.jmeter.timers exists both in src/core and src/components). It can be discussed whether this is a mistake.
One .properties file per src directory would be better, but it's not obvious to implement using the standard JDK APIs.
The best approach is, IMO, one .properties file per component or bean. But then a tool to handle the translation process is a must. I'm building a long-list for that: - RBManager http://oss.software.ibm.com/icu4j/demo_tools/RBManager.html - Zaval JRC Editor http://zaval.org/products/jrc-editor/download/index.html - I18NEdit http://www.cantamen.com/i18nedit.php
Do you know of any other candidates?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
