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.)
This is a rather IMHO complex problem to solve in an a way that ends up "good" for the package maintainer, the user, and from a software perspective too. One solution, is to put translated descriptions into each spec file. That centralizes everything, but when the English description changes, the translations are instantly out of date. Plus, since the spec files are centrally controlled, translators do not have CVS access to them. There are other problems with this method as well, and I think everyone more or less agrees that this soluton is unacceptable overall. Another solution, which was used in Red Hat Linux days, was a separate package named "specspo", which contained the translations for every package's descriptions, etc. This was maintained in a separate CVS repository which was publically accessible, and so translators around the world could update the specspo translations as necessary, without the main rpm package having to be touched. The disadvantages of this approach, were that it was the responsibility of every rpm packager to update the english entries of their packages "%description" fields and whatnot, every single time they changed, or whenever a new one was added or removed, or a new rpm added. This meant double the work for every engineer any time a package description needed to be changed/etc. The process of updating specspo was also very cryptic and non-friendly, and involved hand editing a cryptic file that was incredibly lengthy. Very unweildy and time consuming in general. Also, this solution was bad because it relied on human intervention to actually remember to do these specspo updates, and not forget or make mistakes. If a human mistake was made, then the English description and translated description would be out of sync. In short - specspo sucks. IMHO, the best way for this problem to be solved is for there to be a new solution/process to be created to solve this problem, and for there to be real software tools that automate every step of the process on both the engineering side, and the translator side. Ultimately, a package maintainer really should only ever have to edit the spec file, and from there, automated software tools should do the rest. I don't have a specific proposal for how we might implement this solution, but I think the idea is worthy at least, so I thought I'd offer it as a suggestion. Whatever is chosen as a solution, I believe it only stands a chance of succeeding, if it is given sufficient resources and manpower to see it completed with an eye towards making this a total breeze in the long term, with computers doing most of the work, and humans doing as close to nothing as is possible. It shouldn't be that hard for a tool to pull the spec file out of CVS on checkin, diff it for changes to descriptions, etc. and pull them into something visible by translators. Just a thought... -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
