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

[Daichi Kawahata]

On Sat, 18 Feb 2006 22:35:43 +1030
Clytie Siddall wrote:

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

Okay, no problem at all.

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

At least, a translator can know a package name, but I'm not
sure how to know the exact version without autofiles in the
top directory. Too bad, I can't make sure about that with
those PO file editors (KBabel, poEdit, gtranslator)...

The reason I'd like to see the version in the PO file along
with the package name is, Xfce has now two release lines
(4.2.x, 4.3.x -> 4.4) in its SVN repository. Only appearing
a package name without any information from submitter
confuses us (me, Jean-François).

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

Replaced addresses at Language-Team I had are exact address
they're offering.

> and you submit completed files by email to a robot program,
> which is very thorough.

Currently I am a robot, maybe.

> The same program emails you files to be updated. I waste less
> time on that project than on any other. :)

Probably under the current mechanism in Xfce, a translator
only knows string updates via http://i18n.xfce.org/stats, or
by watching the commit ML, personally I think a notification
sending per every (PO file) diffs can be possible.

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

There's a few rules in Xfce currently, it's not official though,
rather it's from my experiences having (PO file) translation
through several years (7-8).

  1) Don't submit the translations have errors (msgfmt -c).
  2) (If possible), please give enough information to the headers
     (especially lacking/invalid contact address at Last-Translator
     confuses the followers).

Other than that, a translator will do

  1) Grab the PO/source files from the repository.
  2) Have a translation with their preferred editor.
  3) Submit/Commit the translations. 

But basically I don't care the erroneous PO files so much, since
will correct them when I'll commit. Just translated PO files
would be needed here.

BTY, `Commit' at the 3) is, a translator is allowed to commit the
PO files to the repository, note that, only one translator gets the
permission in one language, as far as I know there's no committer
in Vietnamese now.

An easy availability for the PO file translation may be achieved
by using wiki-like web translation on the actual GUI layouts
(screenshots), stdout/stderr will also be illustrated by the
pictures. Still (as one example) Pootle isn't that suitable for
me, it's my opinion.

> 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 frustrated
> about it over time.)

I can understand.
 
> 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.

Okay, thanks.

-- 
Daichi

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