From: Marcelo V. <va...@us...> - 2010-03-28 18:44:12
|
On Sun, Mar 28, 2010 at 2:27 AM, Kazutoshi Satoda <k_s...@f2...> wrote: >> Sometime ago we had some discussion about Chinese translations, IIRC, >> and some caveats of the current way we do translations showed up. > > Could you please summarize, or put the links about, the caveats? > I need that to evaluate your pros and cons. (Are all pros are really > required? Are all cons are really unavoidable?) The main two are: property files need to be in ISO-8859-1, so writing a translation for a language that doesn't fit in that encoding is messy (has to use Unicode escapes). The second, for me at least, is the mix of non-localized and localized content in the same big "jEdit.getProperties()" bag. As for the cons, maybe they can be worked out, but it depends on the cost you're willing to pay. Most of them deal with different ways of doing things, anyway, so it's more of a mindset change than anything else. The "find localizable content" one is the main thing, since it's what translators would care about. We could always write our own parser that does something similar to what xgettext does. I looked at apt for a minute, but it seems very focused on annotations so it wouldn't work for this case, so a more generic Java parser would be needed. (Or owners of plugins could manually maintain a "default translation" file, but that's boring and error-prone.) > Your patch contains many non-essential changes (whitespaces or comment > formatting). Please commit them first, or leave them unchanged, to > simplify the patch and clarify the changes. Yes, those always show up in my patches because I've set up jEdit to follow jEdit's coding guidelines - they say NO whitespace at the end of lines. I wish more people would follow that before checking in code. (Although I can't find a doc saying that right now, I specifically remember Slava posting it a long time ago, including all the other stuff like use of tabs, placement of brackets, etc) I can probably play with git and ask it to create a patch ignoring whitespace changes. > Utf8ResourceBundle looks too hackish. It's confusing to assume .props > files are saved in UTF-8. I found that there is a way to load XML file > as a PropertyResourceBundle via ResourceBundle.Control. But it requires > Java 6. Then, it may be better to require Java 6. Another way may be to > find .xml file manually. It is hackish, but it's the only way I found to do it while still supporting Java 5. In reality, the Sun engineer who came up with that API should be shot. Twice. -- Marcelo Vanzin mmv...@gm... "Life's too short to drink cheap beer." |