From: Marcelo V. <va...@us...> - 2010-03-29 18:55:21
|
On Mon, Mar 29, 2010 at 11:37 AM, Kazutoshi Satoda <k_s...@f2...> wrote: >> That tool is already a hack to work around the stupidity of Sun's API. >> It's really ugly to look at a text file and only see Unicode escapes. >> I'd rather have a little bit of hackish code than to force everybody >> who "doesn't conform" to have to jump through hoops. > > I don't agree. > - Very few people (the translators) have to look into the escaped > file. > - Running a command-line tool is not so much work. What's the real problem with the hack, aside from being a hack? It's a few lines of code that makes the lives of others much easier. And it can probably completely go away when we drop support for Java 5. > Do you know more often case where someone have to look into the > escaped file? Who was suffered from the problem? Try to review a diff that only has escaped unicode characters. Because, you know, nobody ever mistypes anything. >> It's not about performance, it's about semantics. Look at a plugin's >> properties file and tell me what needs to be translated. Look at >> jEdit.getProperty() calls in a plugin's source code, and tell me what >> needs to be translated. > > Then the problem can be solved only in plugins if .props can be > separated into PLUGIN.props and PLUGIN_gui.props, as same as jEdit core. > > This also has worked for Japanese and Chinese translation of jEdit core. And you can't have more than a single translation installed on a system, but hey, nobody has shared installations of jEdit on multi-user systems, right? You also can't have the translations shipped with the code and have them be usable without user intervention. -- Marcelo Vanzin mmv...@gm... "Life's too short to drink cheap beer." |