[Xfce-i18n] Get xfce-goodies po/pot files

[Clytie Siddall]

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:
>
>   http://www.xfce.org/index.php?page=developers&lang=en

Thanks. :)
>
> 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.

Absolutely.

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

Will do.
>
>> 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
>> get.
>
> 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:
>
>   Then,
>   $ 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  
> package.
>   # Daichi Kawahata <daichi at xfce.org>, 2006.
>   #
>   msgid ""
>   msgstr ""
>   "Project-Id-Version: orage 4.3.2.9svn\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-
> Version'.

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  
becomes automatic.

# Vietnamese translation for PROJECT_NAME.
# Copyright © YEAR PROJECT_SPECIFIC.
# TRANSLATOR EMAIL_ADDRESS YEAR.
#
msgid ""
""
msgstr "Project-Id-Version: file_name_and_version\n"
"Report-Msgid-Bugs-To: INPUT_BY_DEVELOPER\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"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0\n"
"X-Generator: EDITOR_INPUT\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  
very effective.

The translation project which has impressed me most is The  
Translation Project at the University of Montréal:

http://www.iro.umontreal.ca/translation/HTML/index.html

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/ 
> iso3166.txt

I noticed this in the message, so I'd like to mention the Translate  
Wiki,

http://translate.sourceforge.net/wiki/

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.

Enjoy. ;)

from Clytie (vi-VN, Vietnamese free-software translation team / nhóm  
Việt hóa phần mềm tự do)
http://groups-beta.google.com/group/vi-VN