lör 2005-06-04 klockan 19:44 -0700 skrev Bryce Harrington:
On Sun, Jun 05, 2005 at 03:33:19AM +0200, Christian Rose wrote:
You're right, it's certainly not 115 very active teams, even though almost all of them are active to some degree. Anyway, when I browsed through the Inkscape po files I found that many of them essentially dated back to the Sodipodi days, so while Inkscape certainly hasn't a big shortage on translations, it seems the situation hasn't been as improving as it could have been doing during the time.
This is true; also the number of translated languages hasn't increased for a very long time.
Judging from http://l10n-status.gnome.org/gnome-2.12/index.html, GNOME has 52 languages that have translation ratios over 50%. Do you think that would be a reasonable estimate for the number of translations Inkscape could expect to have if it were to tap into this resource?
Yes, certainly. Of course it is a difficult estimation, since free software translators essentially work on whatever they want, so it is difficult to predict whether a particular application will gain special attraction from translators or not. There are many factors such as the popularity of that piece of software, the total amount of messages to translate, and how easy or difficult the messages are to translate, that may affect whether translators are happy about translating a particylar application.
But Sodipodi in GNOME CVS currently has translations into 41 languages, whereas Inkscape has 33. Since I think Inkscape has become much more wellknown than Sodipodi, I think an estimation of about 50 languages can certainly be reasonable, given some time of course.
Looking more at the specifics, these are the languages for which Inkscape has translations, but Sodipodi does not (with translated percentage):
es_MX Spanish (Mexico) 26.6% nn Norwegian nynorsk 96.7%
The following are the languages for which Sodipodi has translations, but Inkscape does not:
en_CA English (Canada) 100% en_GB English (Britain) 100% fi Finnish 84.7% hr Croatian 88.6% ko Korean 82.4% mn Mongolian 87.8% pa Panjabi 61.3% rw Kinyarwanda 20.0% sq Albanian 18.9% zh_TW Chinese (traditional) 100%
Translation looks to be pretty simple - for a given language there is just one file to update. Certainly that file is important, but important enough to warrant changing CVS? I guess I'm unclear on particularly why GNOME CVS makes translation so much easier?
I guess I failed to communicate the most important issue here. That issue is:
- Since you're essentially doing your sort of own translation
project with Inkscape, how do you solve issues of translation quality control and peer review?
In other words, what would stop someone else from submitting a poorer Swedish Inkscape translation and having it committed, just weeks after I sent in mine? Do you keep track of your translations and who translates into what language? Do you ask people to confirm that they are ok with translations? Do you ask multiple volunteers for any language to get in contact with each other and sort issues out themselves, or do you just hope that any latest translation sent in by anyone is the one to commit, and hope that any issues will be caught by end users after the next Inkscape release?
These are all good questions, can you explain how the GNOME translation project handles these things? (I didn't see them explicitly explained on the URL you gave.)
Essentially it is up to the teams to decide how they organize their work. The first one that volunteers for translating into a particular language gets to do that, and may become the coordinator for that language if he or she does want that. Then we direct all further volunteers for that language to get in contact with their coordinator first -- we do not accept any translations without approval from the coordinator for the affected language. This may sound harsh, but it helps build up teams and get volunteers to cooperate in their teams, and encourages some sort of peer review. If volunteers should complain that the current coordinator for their language isn't responsive or misbehaves, then we try to deal with that from the GNOME Translation Project side of things, but those situations are fortunately rare. Most of the time, the teams work like ecosystems of their own, producing translations with very little administrative overhead from a central point of view (since they commit their work themselves, and decide on most administrativia themselves). At the same time, enforcing teams makes sure that the translations are reviewed, or at the very least that the translation team for that language beleives that the translators in their team to produce good quality translations and gives them blanket permission to do so.
Exactly how the teams review translations is up to them -- some teams have a very strict policy that everything must be reviewed before being put into CVS, while others, after some initial review of the work of the translator, may give him or her blanket permission.
But in the end, this is all very much like a maintainer/contributor situation with patches and the like. The difference here with translations is that the "project" the team works on is essentially a metaproject: It is all of the modules aggregated in the same repository, instead of a single module. So while in software you have one maintainer per module, and contributors working on (perhaps) different files in that module, but only one contributor per file at the time, in translation the "module" is the complete repository, and the translation contributors are working on different modules, but only one contributor per module at the time.
Taking the analogy to the other end, it gives some hints why having seperate translation teams per software module usually is not a good idea: It would similar to having a software module where every single file had a different maintainer with full decisive control over that file, and no central management. It would perhaps work in some cases, but in most cases it would probably not be a good way to build a consistent product.
Note that the Inkscape Translation team does much more than just translate the software. They also do great work at translating the SVG tutorials and the Inkscape Manual.
The problem with most text-based (or XML-based) formats that include translations is that it is virtually impossible to maintain the translations once they've been completed the first time. In other words, it is often extremely tedious work to figure out whether something changed that requires an update to the translated strings when something has changed, or whether the change was something that doesn't need an update to the translated strings, and then to incorporate the changes. Because of this, it is not uncommon to see translated XML files that represent how the original XML file was ten revisions ago, or being a mess with some changes accidentally left out, while other changes are in, and so on.
This is why we are moving to be using xml2po (part of gnome-doc-utils) in GNOME. That lets us extract the information that should be translated, and only the information that should be translated, from XML files, and then produce XML files from the translated po files. This allows translators to concentrate on the translated content only, with the change detection that po tools already support, and at the same time produce XML files with their non-translateable data and structure being up to date with the original.
Since Inkscape has previous connections to GNOME (using some GNOME technologies, following the HIG, etc.) I thought that using the GNOME Translation Project would be the best choice. However, using the GNOME Translation Project requires that the software be in GNOME CVS. It's simply not feasible for us to educate hundreds of translators how to update a translation in a completely different CVS repository, make them have access to that different CVS, and adopt all our automatic tools (like the translation status pages at http://l10n-status.gnome.org/) to work with that different CVS as well.
What ways exist that would allow your team to do the translations in GNOME CVS without requiring the entire Inkscape project to change CVS systems? Even an approach that was partly manual or otherwise imperfect might at least allow your team to improve Inkscape's state of translation.
Do the translators only work on the .po files, or do they make modifications to files in the codebase itself (e.g. to adjust the original strings)?
Usually not, although some few elite translators are very good at producing bug reports and patches (or commit directly, if allowed) for code or language problems that they encounter when translating. Again, if you think this is desirable, this is very a good reason for using the GTP. I have received comments from many maintainers who do not consider themselves experts in internationalization issues, that they think it is absolutely excellent that translators are able to fix most problems they encounter themselves, without the maintainer or other contributors having to deal with it and resolve it somehow.
From your description, it sounds like you are asking whether there would
be some way for us to synchronize po files with Inkscape, and incorporating Inkscape into the GNOME Translation Project, without Inkscape actually moving to GNOME CVS. The answer is simple: no. The more verbose explanation for this is that we've tried this many times in the past; i.e. hosting pot files and translations for modules that weren't actually in GNOME CVS. Usually some person set it up and offered to do the synchronization with upstream, but eventually it failed in every single case. Synchronization of translations across different repositories is a tedious, unattractive, and boring task. It may also be a complex task when having to deal with conflicts for whatever reason. Also, not everyone can do it, as it requires CVS access to both repositories, and so the (usually) one single person that can do it often becomes a bottleneck, and has either little time to do the synchronization, or little time to spend on something else more fun like actual coding/translating. And when this has eventually happened, there is actually more damage than having no implied synchronization at all: downstream translators think they have translated everything when in reality they have not since they only have access to an outdated pot file, and upstream maintainers not getting updated translations to include in their releases.
We eventually gave up on this approach and refuse to do it anymore. The empirical results of having tried this many times, and it always failing with sad results at some time, made us decide that we would never do it again. Thus, we asked those projects to either move to GNOME CVS, or use another translation project. Some of those translation projects did move to GNOME CVS, while some stayed where they were, and either did use another translation project (like the Translation Project), or didn't manage their translations in a translation project at all, with the expected drawbacks of that.
Now, we *have* seriously considered switching how we manage source code, but I think the general concensus is that we want to move *away* from CVS to something like Subversion, that would give us more powerful code management. Our hope is that SourceForge will eventually implement this, although since SF seems to be taking a long time to get this, I think we'd consider other Subversion providers.
GNOME is currently considering a switch to a replacement for CVS. It's being discussed on the gnome-hackers list (http://mail.gnome.org/archives/gnome-hackers/). Subversion and Arch seems (according to my analysis of the threads) to be the main contenders, although Subversion seems to be the favorite since it has the benefit of being more close to how CVS works.
Interesting, well like I said, if GNOME were to provide Subversion, Inkscape would be very interested in switching to it. Maybe this would be the best way to go? Fwiw, we'd be willing to be beta-testers for the service if it were available.
Nothing is actually decided yet, and it is a sensitive decision that must be handled by the community. However, I think most contributors are supporting a change. The "only" thing that remains is making a formal community decision, deciding what solution we want to move to. Furthermore, key contributors have testified that they want to make sure a decision actually gets made, so that a change can actually happen.
But I don't see this as a reason not to switch now. The current situation is no worse than what you have right now, and there will be a change for something better in the future.
Anyway, you may be right that it would make things more convenient for the GNOME translators, and it's possible that would gain us more translations. On the other hand, it risks making it more difficult for new developers to get CVS accounts, would take a lot of effort to migrate,
As for making sure CVS repository files get imported and making sure accounts get arranged, I promise that I'll help out as much as I can.
If you don't trust my word for it, please ask other people who maintain software in cvs.gnome.org, and what their experiences are on getting CVS accounts arranged for the last year or so. :)
We have over 30 users with CVS access - what would be the process of getting them access? Would each of them have to re-apply for access, or could it be done magically in bulk?
The account details that are needed for gnome.org accounts are at http://developer.gnome.org/doc/policies/accounts/requesting.html, and the mail address to send the details to is accounts@...825... You can send all account requests at once in a single mail with all the details, but they have to be resolved sequentually, one by one. Of course, we would try to make that happen as soon as possible and as swift as possible. Also, please limit the amount of account requests to only active contributors (are all 30 active contributors?).
Christian