With an attached patch and PO file, uim.desktop will be generated via intltool.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.