FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-09-2011, 05:14 PM
Bill Nottingham
 
Default comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in

Jens Petersen (petersen@redhat.com) said:
> yum-langpacks has been working pretty well now for a while in Fedora,
> but all langpacks are still listed conditionally in comps' language support groups
> in addition to the <langpacks> meta-section.
>
> So for F17 I'd like to remove them all from comps,
> this will simplify comps a lot and if we can also
> remove the resulting empty language support groups
> it will also reduce the comps translation burden
> in addition to comps maintenance.

Now that I think about it... removing the empty language
group will remove anaconda/yum's ability to install that
language via kickstart/selection. So we would need to add
some of the things you mention later to maintain some sort
of feature parity.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-09-2011, 06:56 PM
Dimitris Glezos
 
Default comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in

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/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-10-2011, 03:07 PM
Domingo Becker
 
Default comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in

2011/9/9 Dimitris Glezos <glezos@indifex.com>:
> 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.
>

It seems promising.

+1

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.

kind regards

Domingo Becker
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:15 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org