[Xfce-i18n] Get xfce-goodies po/pot files
clytie at riverland.net.au
Sat Feb 18 13:05:43 CET 2006
Thanks for your reply, Daichi. :)
On 18/02/2006, at 7:02 PM, Daichi Kawahata wrote:
>> Are you saying that it's correct for modules not to have a .pot
>> file in their .po directory, when they want that file translated?
> Basically, Xfce-goodies doesn't go the same with Xfce and it has
> separated plugins/modules within it, each of them has own developer/
> maintainer, furthermore, some get ported to the new Xfce-panel with
> i18n support while some still remain old plugin without i18n support.
Yes, I can see that is different.
> That makes somewhat Xfce-goodies difficult for us when it comes with
> one-stop translation (POT/PO) module like po-goodies. FYI, you can
> assume Xfce main repository has that module, see link below:
> by grabbing the modules, you can get POT files in both 4.2, trunk
> tree except Xffms' in trunk. As for the goodies, I think they
> should be i18nized if they show us the strings in the UI too.
> If you find non-i18n supported plugins while should be, file a
> bug at http://bugzilla.xfce.org (product name: Xfce Panel Plugins)
> or ask the authors directly.
>> This is inconvenient at least. We have an increasing number of
>> volunteer translators willing to translate PO files, but not
>> willing to execute command-line tasks to do so. The more we
>> simplify the translation process, the more volunteer effort we
> That may the point I disagree, when a translator finishes the
> translation, to check typo/fitting etc. in the actual situations,
> in other words, in the running applications, at least he/she needs
> to issue the command `make install' from the command line even if
> the location to install is the home directory (due to lack of root
> permission). If a translator want to check the latest trunk
> application, he/she needs to install it from the source.
> Let me say, the translations will be completed with the running
> applications, that is, if you're considering the separating PO/POT
> files from the source tree, only having blind-translation them
> brings a convenience for the new volunteers, it'll bring the another
> (a string inconsistency, style mismatch etc.) instead. Actually,
> an increasing a number of translators doesn't always help.
> Please tell them minimum command lines to get the application
> installed from the source, or probably you/someone take a role of
> a proof-reader/checker if the only GUI-familiar volunteer submits
> a PO file. A translation itself isn't that difficult, the management
> (style unification, consistency etc.) would be, of course it's up to
> the responsible translator in each languages.
Yes, I agree that these tasks have to be done. We're probably going
to have more people sharing the load, though, not everyone having the
skills/time/interest to do them all.
>> It would really help for the internationalization process to
>> include generating a .pot file, if that is not already the case. :)
> As I have a permission to import a missing POT files, let me know
> when you'll encounter them.
Thanks, will do.
>> I'm also puzzled about the modules which do not have po directories.
>> Does this mean they don't want any translations?
> If you were talking about the goodies, yes I was also puzzled,
> again, they're a mixture of old/new Xfce panel API, an i18n
> supported/non-supported. As I have a job title regarding i18n related
> stuffs in Xfce-goodies as well, currently I'm trying to get them
> workable for the translators, time is limited though.
Isn't it always... ;)
>>> Stavros Giannouris <stavrosg2002 at freemail.gr> wrote (in conclusion):
>>> After creating the *.pot file, you should run
>>> $ msginit
>> Is this Xfce-specific?
> Nope, it's just a GNU gettext style (the nearest way to create
> the initial PO file, it's a part of gettext), as far as I know,
Yes, it is. I meant, specific to Xfce that it had to be used.
> except KDE, it can be recommended even in GNOME, a project uses
> wxWidgets (it uses `locale' directory instead of `po'.). Having
> said that however, it's up to you as well to chose a way to
> create the initial PO file if necessary information is given
> (see example below).
> I'm not sure which header you were talking about, for example, in
> Orage, if one follows the step below:
> $ msginit (--locale=vi)
> # Vietnamese translations for orage package.
> # Copyright (C) 2006 THE orage'S COPYRIGHT HOLDER
> # This file is distributed under the same license as the orage
> # Daichi Kawahata <daichi at xfce.org>, 2006.
> msgid ""
> msgstr ""
> "Project-Id-Version: orage 22.214.171.124svn\n"
> "Report-Msgid-Bugs-To: \n"
> "POT-Creation-Date: 2006-01-26 19:58+0900\n"
> "PO-Revision-Date: 2006-02-18 15:45+0900\n"
> "Last-Translator: Daichi Kawahata <daichi at xfce.org>\n"
> "Language-Team: Vietnamese <gnomevi-list at lists.sourceforge.net>\n"
> "MIME-Version: 1.0\n"
> "Content-Type: text/plain; charset=ASCII\n"
> "Content-Transfer-Encoding: 8bit\n"
> "Plural-Forms: nplurals=1; plural=0;\n"
> In the generated headers above, at least the charset should be
> changed to UTF-8, if you have your translation team, Language-
> Team also, however other than that, which would you change?
> Although the problem using this command is, it requires generated
> `configure' script to grab a package name put into `Project-Id-
Apart from the ASCII charset, as you noted, that's pretty much the
header group we use. When you use the same one over and over, it
# Vietnamese translation for PROJECT_NAME.
# Copyright © YEAR PROJECT_SPECIFIC.
# TRANSLATOR EMAIL_ADDRESS YEAR.
msgstr "Project-Id-Version: file_name_and_version\n"
"POT-Creation-Date: 2006-02-16 02:10+0100\n"
"PO-Revision-Date: 2006-02-16 22:59+1030\n"
"Last-Translator: TRANSLATOR EMAIL_ADDRESS\n"
"Language-Team: Vietnamese <gnomevi-list at lists.sourceforge.net>\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms: nplurals=1; plural=0\n"
I have glossary items that input all this for me. Very handy. :)
> At any rate, if only `po' directory is given, PO file editor
> (KBabel, poEdit, gtranslator, vim, emacs) itself can't put the
> correct headers, and manually modified header values would
> include typo. inconsistency & invalid strings. Regarding headers,
> it's not allowed their keeping initial values (because it must
> break build-process due to the error of msgfmt), a missing
> contact address.
No, it has to be correct.
> Note that, that comes from my maintainer's view point, so if
> you can give a consistency across the entire PO files in Xfce/
> Xfce-goodies, I don't care changing the header above, in
> contrast, if you only take care of specific applications and
> PO files get clattered in header-wise by the multiple PO file
> translators/maintainers, it might be the problem for me.
I wish multiple translators were a problem we had. :(
We have very, very few volunteer translators.
Thịnh (who is currently working on Xfce) and I both use the same
header block, so you will have uniform headers.
> At last, in general, a translation process is still under
> construction, especially if one want the separated module for
> the translation only, I know KDE adopts such method but Xfce
> isn't KDE. Nonetheless if you have an idea, don't hesitate to
> post here.
The separate-PO-module idea does, I know, occur in KDE, but other
projects feel it separates the translator too much from the rest of
the program. I'm quite happy with po directories inside modules.
Having PO files accessible from specific l10n team or status pages is
The translation project which has impressed me most is The
Translation Project at the University of Montréal:
It's very efficient, and simplifies the translation process
significantly. You have a team page, which links to a textual domain
for each file, and you submit completed files by email to a robot
program, which is very thorough. The same program emails you files to
be updated. I waste less time on that project than on any other. :)
The more complex your procedure is, the less time we have for
translation (as a translator, you know that yourself). The more
individual your procedure is, the more time translators have to waste
learning it and going through it. Many of us, if not most of us,
translate for multiple projects in the open-source world, so having
to manage different procedures for different projects is confusing
and a significant barrier to contribution.
I feel very strongly about this, since I recently nearly lost one of
our very scarce translators to confusing project procedure/
information (not here). I want fewer barriers and more time available
for actual translating. ;)
(Sorry if this is a bit emphatic, I've become rather frustated about
it over time.)
> And, welcome to Xfce-i18n!
Thankyou very much! :D
> Language Codes: http://www.w3.org/WAI/ER/IG/ert/iso639.htm
> Country Codes: http://www.ics.uci.edu/pub/ietf/http/related/
I noticed this in the message, so I'd like to mention the Translate
an initiative of the Translate project at SourceForge. The Translate
Wiki is a central resource for translators, with a useful and growing
amount of information on the translation process, on different
projects and on resources we can use. Please feel free to make use of
it, and we welcome any contributions. I don't think anyone has added
anything about Xfce yet. The Resources page is particularly useful,
listing things like language codes, country codes, plural forms and
other data specific to different languages.
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm
Việt hóa phần mềm tự do)
More information about the Xfce-i18n