Thread: Translation updates: errors_ru.properties

Translation updates: errors_ru.properties

From
"Serguei Mokhov"
Date:
Hello,

A few more messages translated into Russian.
Please install.

Thanks,

-s

 errors_ru.properties.gz

Attachment

Re: Translation updates: errors_ru.properties

From
Kris Jurka
Date:

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

Re: Translation updates: errors_ru.properties

From
"Serguei A. Mokhov"
Date:
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!

Re: Translation updates: errors_ru.properties

From
Kris Jurka
Date:

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

Re: Translation updates: errors_ru.properties

From
Oliver Jowett
Date:
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

Re: Translation updates: errors_ru.properties

From
"Serguei A. Mokhov"
Date:
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!

Re: Using gettext (was Translation updates: errors_ru.properties)

From
"Serguei A. Mokhov"
Date:
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!

Re: Using gettext (was Translation updates: errors_ru.properties)

From
Kris Jurka
Date:
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




Re: Using gettext (was Translation updates: errors_ru.properties)

From
Kris Jurka
Date:

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!
>

Re: Using gettext (was Translation updates: errors_ru.properties)

From
Kris Jurka
Date:

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