comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in
domingobecker at gmail.com
Sat Sep 10 15:07:28 UTC 2011
2011/9/9 Dimitris Glezos <glezos at indifex.com>:
> On Fri, Sep 9, 2011 at 9:50 AM, Ankitkumar Rameshchandra Patel
> <ankit at 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.
> - 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
It seems promising.
Is there any package we can test it with?
> 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).
It's not a problem.
It will encourage translators participation.
More information about the devel