[Fedora-trans-ja] 翻訳作業に関するアイデア

[Noriko Mizumoto]

おはようございます

以下は 「Re: comps headsup: plan to drop langpacks from 
language-support    groups in comps-f17.xml.in」という件名で i18n リス 
ト、 devel リスト、 trans リストに投稿されたものです。オリジナルメールか 
ら分岐した話題になっているので見落とした方もいるのではと思い転送します。 
今までの翻訳のパッケージ化に関する流れを大きく変えるアイデアに関するディ 
スカッションです。反対派 (ポーランド語翻訳者) と賛成派 (スペイン語、中国 
語、翻訳者) の両者が出ています。個人的には、開発者や翻訳者にとっては便利 
になるけれど、Fedora を日本語で利用するユーザーにとってはどうなんだろ 
う、と疑問に思います。日本語チームとしてどう思われますか?

水本

-------- Original Message --------
Subject: 	Re: comps headsup: plan to drop langpacks from 
language-support groups in comps-f17.xml.in
Date: 	Fri, 9 Sep 2011 21:56:19 +0300
From: 	Dimitris Glezos <glezos ＠ indifex.com>
Reply-To: 	Fedora internationalization discussions 
<i18n ＠ lists.fedoraproject.org>
To: 	ankit ＠ redhat.com, Fedora internationalization discussions 
<i18n ＠ lists.fedoraproject.org>
CC: 	Development discussions related to Fedora 
<devel ＠ lists.fedoraproject.org>, Fedora Translation Project List 
<trans ＠ lists.fedoraproject.org>



On Fri, Sep 9, 2011 at 9:50 AM, Ankitkumar Rameshchandra Patel
<ankit ＠ redhat.com>  wrote:
>  Related note. How about we also change the way we manage translations
>  for packages?
>
>  This gives more control over translations to translators also
>  translators become independent from package maintainers and can reduce
>  burden from package maintainers taking care of translations!
>
>  Shouldn't we have translations packaged independently from RPM packages?

This is indeed possible. We did this in MeeGo and worked quite well. Here's the
workflow we already implemented with MeeGo:

  1. Developer has neither POT or PO files in git. No need to.
  2. Developer builds his package. His Makefile produces the POT on-the-fly and
     includes it in the RPM.
  3. Developer pushes his SRPM on build system. His SRPM contains one POT file
     and no PO files.
  4. Transifex Middleware App monitors the build system for updates on packages.
     It detects a new version of the Anaconda SRPM. It downloads it, extracts
     the POT file from inside and pushes it to Transifex.
  5. Transifex imports the file and notifies all translators if there are new
     strings available.
  6. Translators provide translations either offline or online.
  7. Localization packager uses Transifex client to pull all translations for
     eg. F17 and push a update on the language packs. LPacks are splitted eg. as
     fedora-langpack-ui-pt_BR etc.
  8. User sees an update on yum and installs it.

Advantages:

- Developer is isolated from the need to host translations -- less clutter in
   his repo and changelog.
- Developer does not need to remember to update his POT and pull translations,
   often forgotten (eg. the "pull fresh translations after deadline).
- L10n packager and language teams can push updates to their language any time
   they want.
- CD/DVD can include only a couple of lang packs, so smaller size. Upon
   selection of the language, yum (or even the installer) can download the lang
   pack right away.
- Process works well with release cycles, since there is a string freeze
   period.

Possible drawbacks:

- During Updates cycles (after a release is shipped): Between the time the
   developer pushes his package and the time the lang packs are updated, the
   user may see a couple of English strings on his UI. This happens also when
   the developer hosts his PO files, unless he decides to have small
   string-freezes every time (don't know anyone who does this).

- Need to take extra care to avoid having a new langpack shipped to a user
   every day, since for some countries this might cause issues).

Hope this helps.

-d



-- 
Dimitris Glezos

Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/
--
i18n mailing list
i18n ＠ lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/i18n