Bug 5246

Created attachment 3996 [details] [review]
Suggested patch

In po/POTFILES.in, I've listed files only which contains actual
translatable strings, added Comment string in uim.desktop.in.in,
but it should be revised by the author.

Created attachment 3997 [details]
Japanese translations for UIM 1.0.0

And Japanese translation file (current status 787/804),
in which almost of all strings are translated except
Byeoru related strings and strings have "?" mark
(I was not sure whether those strings were ready to be
translated anyway).

Probably, there might be some incompatibilities, feel free
to adjust them or point them out to me.

Thanks for your suggestion and the patch.
It's really helpful such a careful patch for the translation things.

I'll check this later and will commit.

Also big thanks for your improvement on ja.po.

I have some comment on it.

  We use 'uim' not 'UIM'.
  'toggle' doesn't mean 'switch'
  'advance' doesn't mean 'for expert'.
  ...

YamaKen, do you have any comment about the Japanese translations (especially on
the technical term side)?

Created attachment 3999 [details]
Japanese translations ver. 2

Okay fixed, make sure if FIXME marked strings really need
to be revised, and from what I've seen certain amount of
strings in Byeoru seems just transliterations, which may
require asking English translation to the author of that
module.

BTW, just out of curiosity, as far as I know, isn't uim
abbreviation of Universal Input Method?

Created attachment 4000 [details]
Japanese translations ver. 2

Oops, still UIMs there were...

I revised "Japanese translations ver.2" and here is the patch against the file.
I'll commit "ver2" with my patch applied.

YamaKen, please check when you have a free time.

Created attachment 4003 [details]
Patch for "ver 2"

Created attachment 4006 [details]
Japanese translations ver. 3 (semi-final)

No, I just found that my local repository (svn://svn.utyuuzin.net/uim/trunk)
didn't get sync'd with yours at all, I must make a mess against previous
translations. Therefore I've reverted translations at the most part so that
only new strings are translated by me.

YamaKen, sorry for discarding your credit and translations, which have
certain advantages than mine. Now translation comes back in your hand, feel
free to re-modify them (current status 796/804 and strings with FIXME really
require to be fixed), especially Chinese related strings (e.g. I put Kanji
at "Pinyin", different translation in "Traditional").

As for the translation style in GNOME (helper/GNOME_UimApplet.server.in.in),
the words in single sentence need to be punctuated by middle dot for the
sake of their translation consistency. Also I've put a space in between
ASCII character and Japanese, if that was not your style, tell me so.

PS. As I couldn't update my local SVN repository (I got an error), I have to
upload entire PO file again instead of patch, sorry in advance for your
inconvenience.

Created attachment 4007 [details] [review]
Reference patch for the reversion

I hope translation gets consistency again and improved somehow.

Daichi, thank you for the contribution. It has significantly improved our
translation quality and consistency.

I have not looked at your last work yet because another important problem has
appeared.

The problem is that some message-ID is conflicting, such as "Hebrew". The ID is
appeared as language name in libuim, and as Unicode character category name in
chardict-qt. They should be translated to different Japanese message. I think
that we should separate po files for each libuim, bridges and helper
applications as proper responsibility separation. It also resolves the ID
confliction. Etsushi, how do you think about?

>The problem is that some message-ID is conflicting, such as "Hebrew". The ID is
>appeared as language name in libuim, and as Unicode character category name in
>chardict-qt. They should be translated to different Japanese message. I think
>that we should separate po files for each libuim, bridges and helper
>applications as proper responsibility separation. It also resolves the ID
>confliction. Etsushi, how do you think about?

OK. I'll investigate how to deal with multiple po.
I think that it isn't so easy to setup po file corresponding to each application
with our current directory structure.  But creating po file with each directory
will be much easier.

>OK. I'll investigate how to deal with multiple po.
>I think that it isn't so easy to setup po file corresponding to each application
>with our current directory structure.  But creating po file with each directory
>will be much easier.

I now understand above strategy doesn't work well, since any application using
libuim and its own directory's po file need to switch domain names appropriately.

So for the workaround of translation problem between uim-chardict-qt and libuim
in 1.0.0, I'm going to create qt/chardict and use qt/chardict/po only for
qt-chardict, since qt-chardict doesn't use libuim at all.

How about g_strip_context() and N_("language_code|Hebrew")?
Because of GLib function, uim/iso-639-1.def has to be the place
to apply this workaround, also macro definition may require
somewhere.

I'm not sure if Qt has similar function, but if Qt provides
such function, qt/chardict-unicodeviewwidget.cpp is the best
place to put the translation context label, like
UnicodeBlock( _( "character_name|Hebrew" ), in my opinion.

Using different gettext domain might be the another path to
resolve the problem.

> also macro definition may require somewhere.

It meant NC_("language_code|Hebrew"), macro C (Context or Conflict) or
the like, as well as UnicodeBlock( C_( "character_name|Hebrew" ), the
former requires noop+context_strip macro/function, the latter requires
the macro/function in C++, hmm...

Thank for the information.  I didn't know g_strip_context().

Sadly we don't use glib with libuim and I couldn't find any equivalence in Qt
and/or gettext.  But adding g_strip_context() equivalent mechanisms in libuim
(handling 'Q_') seems to be easy and work fine for this situation.  I'll test later.

I've tested both approach, creating qt/chardict/ and use its own domain for
uim-chardict-qt, and add uim_pvt_strip_context() and use Q_ for it as in
g_strip_context() in glib.

With Q_ approach, it is impossible to use this in uim/iso-639-1.def since
uim-util.c uses it as a static table.  But of course it works fine with
qt/chardict-unicodeviewwidget.cpp as Q_( "charactor_name|Hebrew" ).

YamaKen, which way do you prefer to use?

> Using different gettext domain might be the another path to
> resolve the problem.

It's the proper way I supposed. But applying it to all libuim/bridges/apps is
not required for now. Separating the qt-chardict is sufficient for uim 1.0.

According to my past Qt programming experience, Qt provides its own
gettext-equivalent facility. tr() for '_', QT_TR_NOOP() for 'N_', *.ts for *.po,
and *.qm for *.mo. It may easily be supported by build scripts and I think that
Qt apps should use it instead of gettext. It can also automatically separate the
messages. Kazuki, how much work does it need?

> I've tested both approach, creating qt/chardict/ and use its own domain for
> uim-chardict-qt, and add uim_pvt_strip_context() and use Q_ for it as in
> g_strip_context() in glib.

Former way is preferable. Thank you for the work.

Here is current precedence.

1. comment #18 (Qt's own gettext-equivalent facility)
2. the former way
3. complete separation for each uimlib, bridges, helper apps

> Here is current precedence.
> 
> 1. comment #18 (Qt's own gettext-equivalent facility)
> 2. the former way
> 3. complete separation for each uimlib, bridges, helper apps

OK.  Since there is no response from kazuki yet and 1. (using Qt linguist)
requires some changes in build process, I'll take 2. (using another gettext
domain for uim-chardict-qt) for uim-1.0 series.

Execuse me for my late response. And don't know further information about Qt     
i18n issue, I always use KDE's gettext system to use gettext facility.     
    
I saw the Qt document and I've found qtlingust    
(http://doc.trolltech.com/3.3/linguist-manual.html) is the very tool for translation    
tool of Qt. And as Etsushi already suggests, using qtlingust requires build process. 

OK change resolution to FIXED.  Now uim-chardict-qt uses it own domain, and the
semi-final patch has been integrated to the repository and revised by YamaKen.