On Mon, 2005-11-14 at 15:04 -0500, Elliot Lee wrote: > On Tue, 8 Nov 2005, Yuan Yijun wrote: > > > Greetings, > > > > I believe that non-English speakers will be more happy to see > > localized package %descriptions, when they are using a GUI package > > management program. Most of users play Linux for fun, and they are > > willing to search software in the huge packages list, looking for > > interesting packages to install. But this fun only belongs to English > > speakers. To Chinese, there is no way for an software package to > > introduce itself. > > > > Then how can these %descriptions be localized? If someone translate > > them and commit patches to rpm spec files, that seems a bit funny and > > boring. (Sorry for my bad vocabulary, though the single filed rpm spec > > does have its cons and pros.) How to simplify this and reduce the > > amount of work? > > > > (There are too many excellent programs in both Core and Extras, while > > I'm trying to introduce them to other Chinese users, I believe this > > problem is essential.) > > Currently, specspo is meant to be the means by which package strings are > translated. However, specspo has not been maintained in a long time and > could use a lot of love. If someone wants to pick it back up, the work > that needs to be done is a fairly well understood problem. It's just a LOT > OF WORK. :) For Extras (with it's rolling release), specspo's issues are more pronounced than in Core. Core has a string freeze before release that Extras (which doesn't have a "release") lacks so translations would get out of sync. End-user Goals: 1) See package descriptions in the user's native language. 2) End-users don't end up downloading an update just because the translations change. 3) End-users don't end up downloading updated specspo because translations for a language/package they don't use is updated. Packager Goals: 1) Transparent. The packager does not have to think about translations. They just happen. Translator Goals: 1) Notification of package string changes. 2) Ability to own a package-translation similar to how other packagers own a package. Packager and translator goals seem like they could be solved with good infrastructure. Add a check for string changes into make build or make tag that extracts necessary information and hands them off to a translation system that emails translators of changes, updates websites, etc. The end-user goals point at the drawbacks of both in-package translations and the specspo centralized translations. Alternatives that spring to mind: perpackage-perlanguage specspo. No more downloading of unnecessary files but it seems pretty darn unattractive. Lots of rpm metadata overhead, multiple new packages for each existing package... Just say ick. Auto-merging of translations at make build if the description hasn't changed: translations are kept separate from the spec file. When make build is run, if the spec %description has been updated, a message is sent to the responsible translator to update. Otherwise the translation is merged with the spec file and the build started. Translations will always lag packaging changes, but this works when %description doesn't change too often. Could be annoying to end-users who read a description of one version of a package in their native language but when they go to install on another machine, the description is in English (because the English description was updated.) perlanguage specspo. The end user still has to keep it updated anytime a description changes. The package could be rebuilt on a time/change basis (ie: once a month when changes occured in that month.) Talk with Seth about pushing the issue out to rpm-metadata. End-users are already downloading new versions of the metadata anytime a string changes. rpm-metadata aware applications (yum, yumex, smart) will be the most frequent interfaces to the packages and could see the translations (but rpm would not). Would localized versions of the metadata (in separate language files) cause issues? Currently createrepo creates the rpm-metadata by parsing the packages. If the translations weren't in the packages then this is a significant departure.... Any other ideas? -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
