O/H Jeffrey C. Ollie έγραψε:

I've started working on internationalization for Smolt. It's not ready to commit to the main smolt repository, as it's not complete and I'm sure I've committed some boneheaded mistakes because I've never done any internationalizing of code before. I've set up a separate Mercurial repository here. You can access it through the web here:

http://hg.ocjtech.us/smolt-i18n

or check out a copy of the code:

hg clone http://hg.ocjtech.us/smolt-i18n

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

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

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.

Hosted elsewhere ================

Basically, same as the second, but 2a. is not an option here. (Note: Translators have showed preference to use only one SCM.)

Conclusion ==========

I, as a translator, would really like to have 2b. for every project not hosted on `cvs.fp.org`. Otherwise, I don't see a way I could handle different SCMs *plus* having to request CVS access to every project hosted elsewhere.

Hope the above helped give a better picture.

-d

On Wed, 2007-03-14 at 21:23 +0000, Dimitris Glezos wrote:

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

This is the simple case and is basically all that we can do today.

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

Yeah, this is no fun at all for translators. Hence, while it can "work", it's not really what we'd want to happen.

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

This is really what we *have* to be able to do... it's the only thing that scales while not complicating things for either translators or developers. And making things complicated for either party means that things don't get done -- either files don't get moved around or translations don't get committed or ...

The big problem here is that there is code that has to be written. This is the entire crux of the discussion we had ~ 2 weeks ago on IRC.

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.

This is the way that translations worked for quite a while and were a huge problem. String and translation freezes don't do anything to make this easier as you really don't want to just get all the pot files dropped on you at once to have to translate in a very short time. And then have the translated strings be pulled in and only have one chance (maybe) for corrections. Instead, you want to be able to be integrated with the development process so that new strings are available for translation as they're added to the code and new translated strings are available for testing as soon as releases are built. It's the only way to scale things.

Hosted elsewhere

Basically, same as the second, but 2a. is not an option here. (Note: Translators have showed preference to use only one SCM.)

The answer here really needs to be to work with the project which is hosted elsewhere to either a) provide translations to them directly or b) convince them that the benefits of translations make it worthwhile to be hosted on fp.org.

This is the exact same thing that, eg, GNOME modules go through. If you want the advantages of being translated by the GNOME translation team, then you host your app on svn.gnome.org instead of sourceforge or whatever. Especially if we can hit 2b and have a nice way of integrating between different SCMs, then this actually has the possibility of being pretty compelling.

Jeremy