Обсуждение: Translation updates: errors_ru.properties
Hello, A few more messages translated into Russian. Please install. Thanks, -s errors_ru.properties.gz
Вложения
On Wed, 6 Oct 2004, Serguei Mokhov wrote:
> A few more messages translated into Russian.
> Please install.
Done. Thanks.
Note though that new messages do not get propagated into the
various error message files. Note:
$ wc -l err*
133 errors.properties
78 errors_de.properties
6 errors_fr.properties
117 errors_hu.properties
75 errors_it.properties
65 errors_nl.properties
111 errors_pl.properties
135 errors_pt_BR.properties
118 errors_ru.properties
109 errors_zh_TW.properties
I don't know if this is supposed to be done by the person doing the
translation or the person updating the base errors.properties file. In
any case your still short some messages.
Kris Jurka
On Wed, 6 Oct 2004, Kris Jurka wrote: > Date: Wed, 6 Oct 2004 14:27:45 -0500 (EST) > On Wed, 6 Oct 2004, Serguei Mokhov wrote: > > > A few more messages translated into Russian. > > Please install. > > Done. Thanks. Thank in return ;-) > Note though that new messages do not get propagated into the > various error message files. Note: :( > $ wc -l err* > 133 errors.properties > 78 errors_de.properties > 6 errors_fr.properties > 117 errors_hu.properties > 75 errors_it.properties > 65 errors_nl.properties > 111 errors_pl.properties > 135 errors_pt_BR.properties > 118 errors_ru.properties > 109 errors_zh_TW.properties > > I don't know if this is supposed to be done by the person doing the > translation or the person updating the base errors.properties file. In > any case your still short some messages. Peter E. and the pgAdmin team make it easier for translators by maintaing the pages [1] and [2], with the new strings automatically merged in, to ease up the job of translators who don't have necessarily the source tree installed and possibly gettext or otherwise tools. [1] http://developer.postgresql.org/~petere/nls.php [2] http://www.pgadmin.org/pgadmin3/translation.php It'd be cool if the JDBC project had a similar page updated daily or some such, because it's a bit more tedious with the .properties files to find what's missing than with .po files. I will update the _ru translation to the current state soon. > Kris Jurka > -- Serguei A. Mokhov | /~\ The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | X Against HTML Montreal, Quebec, Canada | / \ Email!
On Thu, 7 Oct 2004, Serguei A. Mokhov wrote: > Peter E. and the pgAdmin team make it easier for translators by maintaing > the pages [1] and [2], with the new strings automatically merged in, to > ease up the job of translators who don't have necessarily the source tree > installed and possibly gettext or otherwise tools. Well these projects are a little different because they do use gettext which automatically produces the po files. We considered using gettext for the JDBC driver, but kind of stalled because we did not want to add any build dependencies. We could do this by checking the compiled files into cvs, but that isn't ideal either. I'd still like to move to gettext because I think the current system is error prone (and more work) for both developers and translators. > It'd be cool if the JDBC project had a similar page updated daily or some > such, because it's a bit more tedious with the .properties files to find > what's missing than with .po files. There are probably tools to compare properties files and merge them accordingly, but I'm not immediately aware of them. The problem is when the English message changes there is no way to notice and update the translated message. In the end I think the correct solution is to move to gettext. Kris Jurka
Kris Jurka wrote: > > On Wed, 6 Oct 2004, Serguei Mokhov wrote: > > >>A few more messages translated into Russian. >>Please install. > > > Done. Thanks. > > Note though that new messages do not get propagated into the > various error message files. [...] > > I don't know if this is supposed to be done by the person doing the > translation or the person updating the base errors.properties file. In > any case your still short some messages. If you put a "blank" message into the localized files (i.e. "postgresql.some.error=") will it prevent the fallback to the bare untranslated message ID in MessageTranslator? That would be bad. I don't usually touch the localized files for that reason. We really do need a better (less developer-intensive) localization mechanism :( -O
On Thu, 7 Oct 2004, Kris Jurka wrote: > Date: Thu, 7 Oct 2004 12:37:01 -0500 (EST) > > On Thu, 7 Oct 2004, Serguei A. Mokhov wrote: > > > Peter E. and the pgAdmin team make it easier for translators by maintaing > > the pages [1] and [2], with the new strings automatically merged in, to > > ease up the job of translators who don't have necessarily the source tree > > installed and possibly gettext or otherwise tools. > > Well these projects are a little different because they do use gettext > which automatically produces the po files. We considered using gettext > for the JDBC driver, but kind of stalled because we did not want to add > any build dependencies. We could do this by checking the compiled files > into cvs, but that isn't ideal either. I'd still like to move to gettext > because I think the current system is error prone (and more work) for both > developers and translators. > > > It'd be cool if the JDBC project had a similar page updated daily or some > > such, because it's a bit more tedious with the .properties files to find > > what's missing than with .po files. > > There are probably tools to compare properties files and merge them > accordingly, but I'm not immediately aware of them. The problem is when > the English message changes there is no way to notice and update the > translated message. Totally agree with you on all of the above. > In the end I think the correct solution is to move to > gettext. When do you think that might happen? > Kris Jurka > -- Serguei A. Mokhov | /~\ The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | X Against HTML Montreal, Quebec, Canada | / \ Email!
On Thu, 7 Oct 2004, Kris Jurka wrote: > Date: Thu, 7 Oct 2004 17:27:15 -0500 (EST) > > Unfortunately no one seems to be using gettext and Java together. > Searching google for "java gettext translation" unfortunately comes back > with the first result of my message to the list in January noting the > pros/cons of using gettext for our jdbc driver. How do other large Java > projects handle this? 130 messages isn't really all that many, how > can a big project cope? They use gettext! :-) I googled for java+gettext+gnu and found: http://www.gnu.org/software/gettext/manual/html_chapter/gettext_13.html#SEC205 Citation: ------------------------------------8<----------------------------------- 13.5.10 Java RPMs java, java2 File extension java String syntax "abc" gettext shorthand _("abc") gettext/ngettext functions GettextResource.gettext, GettextResource.ngettext textdomain ---, use ResourceBundle.getResource instead bindtextdomain ---, use CLASSPATH instead setlocale automatic Prerequisite --- Use or emulate GNU gettext ---, uses a Java specific message catalog format Extractor xgettext -k_ Formatting with positions MessageFormat.format "{1,number} {0,number}" Portability fully portable po-mode marking --- Before marking strings as internationalizable, uses of the string concatenation operator need to be converted to MessageFormat applications. For example, "file "+filename+" not found" becomes MessageFormat.format("file {0} not found", new Object[] { filename }). Only after this is done, can the strings be marked and extracted. GNU gettext uses the native Java internationalization mechanism, namely ResourceBundles. To convert a PO file to a ResourceBundle, the msgfmt program can be used with the option --java or --java2. To convert a ResourceBundle back to a PO file, the msgunfmt program can be used with the option --java. Two different programmatic APIs can be used to access ResourceBundles. Note that both APIs work with all kinds of ResourceBundles, whether GNU gettext generated classes, or other .class or .properties files. The java.util.ResourceBundle API. In particular, its getString function returns a string translation. Note that a missing translation yields a MissingResourceException. This has the advantage of being the standard API. And it does not require any additional libraries, only the msgfmt generated .class files. But it cannot do plural handling, even if the resource was generated from a PO file with plural handling. The gnu.gettext.GettextResource API. Reference documentation in Javadoc 1.1 style format is in the javadoc1 directory and in Javadoc 2 style format in the javadoc2 directory. Its gettext function returns a string translation. Note that when a translation is missing, the msgid argument is returned unchanged. This has the advantage of having the ngettext function for plural handling. To use this API, one needs the libintl.jar file which is part of the GNU gettext package and distributed under the LGPL. ------------------------------------8<----------------------------------- > Kris Jurka > > > -- Serguei A. Mokhov | /~\ The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | X Against HTML Montreal, Quebec, Canada | / \ Email!
Unfortunately no one seems to be using gettext and Java together. Searching google for "java gettext translation" unfortunately comes back with the first result of my message to the list in January noting the pros/cons of using gettext for our jdbc driver. How do other large Java projects handle this? 130 messages isn't really all that many, how can a big project cope? http://archives.postgresql.org/pgsql-jdbc/2004-01/msg00220.php I'm still in favor of using it, and perhaps simply checking in the generated class files will be OK. Kris Jurka
On Thu, 7 Oct 2004, Serguei A. Mokhov wrote: > They use gettext! :-) > > I googled for java+gettext+gnu and found: That wasn't the quer > > http://www.gnu.org/software/gettext/manual/html_chapter/gettext_13.html#SEC205 > > Citation: > > ------------------------------------8<----------------------------------- > 13.5.10 Java > > RPMs > java, java2 > > File extension > java > > String syntax > "abc" > > gettext shorthand > _("abc") > > gettext/ngettext functions > GettextResource.gettext, GettextResource.ngettext > > textdomain > ---, use ResourceBundle.getResource instead > > bindtextdomain > ---, use CLASSPATH instead > > setlocale > automatic > > Prerequisite > --- > > Use or emulate GNU gettext > ---, uses a Java specific message catalog format > > Extractor > xgettext -k_ > > Formatting with positions > MessageFormat.format "{1,number} {0,number}" > > Portability > fully portable > > po-mode marking > --- > Before marking strings as internationalizable, uses of the string > concatenation operator need to be converted to MessageFormat applications. > For example, "file "+filename+" not found" becomes > MessageFormat.format("file {0} not found", new Object[] { filename }). > Only after this is done, can the strings be marked and extracted. > > GNU gettext uses the native Java internationalization mechanism, namely > ResourceBundles. To convert a PO file to a ResourceBundle, the msgfmt > program can be used with the option --java or --java2. To convert a > ResourceBundle back to a PO file, the msgunfmt program can be used with > the option --java. > > Two different programmatic APIs can be used to access ResourceBundles. > Note that both APIs work with all kinds of ResourceBundles, whether GNU > gettext generated classes, or other .class or .properties files. > > > The java.util.ResourceBundle API. > In particular, its getString function returns a string translation. Note > that a missing translation yields a MissingResourceException. > > This has the advantage of being the standard API. And it does not require > any additional libraries, only the msgfmt generated .class files. But it > cannot do plural handling, even if the resource was generated from a PO > file with plural handling. > > > The gnu.gettext.GettextResource API. > Reference documentation in Javadoc 1.1 style format is in the javadoc1 > directory and in Javadoc 2 style format in the javadoc2 directory. > > Its gettext function returns a string translation. Note that when a > translation is missing, the msgid argument is returned unchanged. > > This has the advantage of having the ngettext function for plural > handling. > > To use this API, one needs the libintl.jar file which is part of the GNU > gettext package and distributed under the LGPL. > ------------------------------------8<----------------------------------- > > > > Kris Jurka > > > > > > > > -- > Serguei A. Mokhov | /~\ The ASCII > Computer Science Department | \ / Ribbon Campaign > Concordia University | X Against HTML > Montreal, Quebec, Canada | / \ Email! >
On Thu, 7 Oct 2004, Serguei A. Mokhov wrote: > On Thu, 7 Oct 2004, Kris Jurka wrote: > > > > Unfortunately no one seems to be using gettext and Java together. > > Searching google for "java gettext translation" unfortunately comes back > > with the first result of my message to the list in January noting the > > pros/cons of using gettext for our jdbc driver. How do other large Java > > projects handle this? 130 messages isn't really all that many, how > > can a big project cope? > > They use gettext! :-) > > I googled for java+gettext+gnu and found: That's not what this shows. The search result shows that gettext has some support for Java. We already knew that. In the email I cited I included a sample Java project built with gettext support. The question was what other Java projects are actually using gettext, and I haven't seen any search results showing anyone actually using this functionality. This naturally makes me a bit suspicious because it looks like an obvious at first solution. Kris Jurka