lyonplus / gettext-commons

Automatically exported from code.google.com/p/gettext-commons
GNU Lesser General Public License v2.1
0 stars 0 forks source link

I18n.trc() implementation does not match javadoc #32

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Use I18n.trc(context, text) with arguments like trc("chat (noun)", "chat")
2. The translation to another language will attempt to look up "chat
(noun)\u0004chat" instead of "chat (noun)"

What is the expected output? What do you see instead?

The method comment and the way gettext extracts strings suggest that only
context will be translated, not a concatenation of context and text:

 * @return <code>text</code> if the locale of the underlying resource
 *         bundle equals the source code locale, the translation of
 *         <code>comment</code> otherwise.

The testcase (I18nTest) tests for a different behavior, where the context
is only a disambiguation string without containing the text ("(noun)"
instead of "chat (noun)". 
This will lead to problems with the string extraction, as the text to
translate will show up as "(noun)" in the catalog.po file, thus making
translations difficult.

What version of the product are you using? On what operating system?
gettext-commons 0.9.6

Please provide any additional information below.

Proposed fix:

public final String trc(String context, String text)
{
    if (sourceCodeLocale.equals(getResources().getLocale())) { 
        return text;
    } else {
        String translated = tr(context);
        // if no translation was found return text in source locale
        return translated == key ? text : translated;
    }
}

Same holds for the method
I18n.trnc(String context, String singularText, String pluralText, long n)

Original issue reported on code.google.com by tobiaskr...@gmail.com on 26 Mar 2009 at 2:33

GoogleCodeExporter commented 8 years ago
The documentation has been updated in subversion, so I think this is fixed now. 
If
not, please reopen. Thanks!

Original comment by berge...@gmail.com on 21 Dec 2009 at 1:08

GoogleCodeExporter commented 8 years ago
I think the problem was not the documentation, but the implementation:
We used to be able to use code like this:
trc("chat (noun)", "chat");
which shows up in the .po file as "chat (noun)".

Since version 0.9.6, the I18n.trc() methods will try to look up a concatenation 
of
context and English string, forcing us to write something like this:
trc("(noun)", "chat");

But: the string will only be extracted as "(noun)" in the .po file, making it 
more or
less unusable.

I wonder if this is somehow the intended behavior and I'm missing the point?

And maybe the title of this issue should be changed to something less 
misleading.

Original comment by tobiaskr...@gmail.com on 16 Mar 2010 at 10:58

GoogleCodeExporter commented 8 years ago
yes, we changed the inner workings of this which breaks existing translations 
with new versions of the library.

The reason is that the native gettext tools added proper message context 
handling to their Java implementation.

Switching to the official way of handling message context uses the full syntax 
of the generated .pot file and allows 
translation tools to display the context information better to translators.

Original comment by berge...@gmail.com on 20 Mar 2010 at 10:49