Smolt I18N
Mike McGrath
mmcgrath at redhat.com
Wed Mar 14 21:34:30 UTC 2007
Dimitris Glezos wrote:
> Great!
>
> So, let me grab this opportunity to see our future possibilities for maintaining
> translations. I see us having three different scenarios in terms of hosting.
>
> 1. A project is hosted on `cvs.fedoraproject.org` (example: Docs)
> 2. A project is hosted on `hosted.fp.org` (example: Smolt)
> 3. A project is hosted elsewhere (example: yum)
>
>
> `cvs.fp.org` hosted
> =================
>
> The first is quite easy to handle: we give read-write access to 'cvsl10n' group
> at the 'po/' subdirectory of each project. Translators use their FAS to checkout
> & checkin translations. A WUI shows statistics. Everything is great. The Docs
> project already decided to do it this way (and so will other projects if they
> move development off elvis).
>
Note: as far as actual servers go, hg, git and cvs are all being hosted
at cvs.fedoraproject.org.
> `hosted`-hosted
> =================
>
> The second is more tricky since PO files are hosted on a different server & SCM
> of what translators use. Furthermore, the WUI needs somehow to "get" the
> statistics and show them together with the other ones. Three choices here:
>
> 2a. POs are hosted on `hosted` too. Translators can use the system with their
> existing FAS-account. We give them simple directions on how to use the different
> SCM (checkin, checkout, diff). Easier for maintainer, harder for translators.
>
This should be fairly simple to set up though I'm not that familiar with
acls in mercurial right now.
> 2b. Same as 2a, but translators can submit the PO files from the WUI (addon to
> 2a, not substitute). The WUI will act as a SCM client (will need to be able to
> handle many types of SCM systems and be given commit access to po/ subdirs).
>
> 2c. The maintainer chooses to handle the burden and copies the POs over on
> `cvs.fp.org`, our "main" translation system when they need translation. Jesse &
> Jeremy tried this and said it is ugly. However, some maintainers might want to
> do it to ease the translators' job. With string & translation freeze dates, this
> might get easier.
>
I agree, some maintainers may want this. In smolts case the strings
probably won't change much and I'd be happy to treat the translators as
'upstream' for translations. In that scenario at least the translators
get to keep on one, common, SCM and the hosted project can use whatever
they want. There are drawbacks, its kind of nasty, and causes duplicate
bits.
-Mike
More information about the Fedora-infrastructure-list
mailing list