On Tue, 2007-03-06 at 22:02 +0000, Dimitris Glezos wrote: > ## String freezes > > For F7, the RelEng team has introduced string freezes in the schedule [2]. This > means that application strings for F7 should be complete *by 19/3*. Translations > made after this date (and before the freeze) should be guaranteed to be included > in the release. > > [2]: http://fedoraproject.org/wiki/Core/Schedule Yep -- this should hopefully help a lot, although I expect it will take a release or two to fully institutionalize itself. We should probably have a procedure to be followed for cases where strings need to be changed. Here's a shot in the dark: String Freeze Policy. As of the string freeze date, translatable strings should not change to help ensure high quality translations for the Fedora 7 release. If you have a case where you need to change a string after this date, please send notification to fedora-trans-list. Alternately, we could make it a "get approval from the release team and then send notification", but I'm not sure if we want to go to that level for the first time through. Another important part is that if translators notice string changes after the string freeze, mail should be sent to the maintainer of the package and probably fedora-devel-list as well make sure they realize the problem. > To do this we need to try not to add new strings after the freeze and let the > L10n folks know if they need to do so. Also, maintainers should repackage before > each release (and after the translation freeze) without a bug needing to be > opened. Yep > ## CVS convergence > > Right now translations are done on `i18n.redhat.com`. This requires contributors > to have one account on the Fedora Account System (FAS) and a different > one for translations. With the merge of Core and Extras, now is a good > point to get rid of this distinction. > > The plan is to move all PO files on Fedora infrastructure under a new > CVS group (cvsl10n) [3]. An email will be sent to all translators to create a > FAS account if they don't have one and join the cvs group. Members of the L10n > team and ambassadors will help with this process. > > [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure Does this also include moving the actual source that's hosted on elvis/i18n? If not, then I have very strong concerns... separating the source code from the translations has a lot of downsides as it requires a manual sync between the two. And these never work well :( > At this point we could discuss the idea for Fedora to act as upstream for > the translations of outside-hosted projects such as yum, smolt, and > pungi. The proposal is to host and maintain those project's > translations with the existing Fedora L10n community. See above :-) Although there's definitely a need for some problem solving here, as there is plenty of desire to have projects hosted in non-CVS SCMs as well. > ## Packaging translations > > One final plan (and probably the one that needs most discussion) is about > changing the way we package translations. Right now PO files live inside the > application and are packaged there (GNOME-style). The plan is to move the PO > files in to their own directory and distinct package [4] (KDE-style langpacks). > > [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage I'm very very very very strongly opposed to doing this. It's a nitemare from an installation point of view and also from a space point of view. The packages which do translations like this require absolutely horrible hacks within our software management stack to even have a *chance* of people getting the translations installed for their apps. Contrast to the apps which include the translations in the package... install the package and voila!, you have the translations for it. > Cons: L10n team should maintain a package (or many) and packages should be > altered to accomodate the different locations of PO files. Con: makes the source COMPLETELY divorced from the translations. So if I update an app and you don't update the translation package, all new strings aren't translated. Unless you push a new (massive) translation package. This does not scale. > Pros (many): increased modularity and maintenance (L10n repackages at > will). App packages will be smaller in size -- we could provide > one langpack or different ones per language. The size difference for most of the app packages are going to be negligible. But now, to push a new pirut with new strings, I also have to coordinate the pushing of n langpack packages. Which are each significantly larger than the amount you save on the app packages. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
