lör 2005-06-04 klockan 16:22 -0700 skrev Bryce Harrington:

On Sun, Jun 05, 2005 at 12:38:50AM +0200, Christian Rose wrote:

...

I'd like to ask a question (or rather two):

• Are there any plans on using GNOME CVS and GNOME Bugzilla

for Inkscape development?

We've been using SourceForge CVS since the project started. Sodipodi (Inkscape's predecessor) was in GNOME CVS. At the time, getting a CVS account for GNOME was a bit too manual of a process (requiring bugging GNOME administrators.) Those of us who had been Sodipodi developers had found that being allowed access to GNOME CVS was difficult and time consuming; IIRC it took several months for me to get GNOME CVS access.

I'm quite sure things have improved since then. Typically, the time span for getting an account nowadays is between a few hours and a couple of days at most.

Also, since Inkscape was born as a fork of Sodipodi, there was also some worry that GNOME would not allow us to use their CVS.

Oh, that shouldn't have been a worry at all. There are several projects in GNOME CVS that are essentially forks of other software in GNOME CVS. Epiphany is a good example; it started as a fork of Galeon. Both projects are still using GNOME CVS, and there was never any controversy over that. The only controversy was over which one of them should eventually go into the GNOME Core release, but that was a totally different matter.

The main downside we faced was that we'd lose the involvement of the GNOME translators, which we'd had very good experiences with in Sodipodi. A second downside is that SourceForge CVS has been problematic (and slow) compared with GNOME CVS.

However, despite being outside GNOME's translation community, we've nonetheless gained very good involvement from translators. Certainly not 115 languages, but then my guess is that many of those languages are not actively maintained anyway, and that Inkscape would not gain translations into more than a few new languages.

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.

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?

Even if you do try to take care of these issues by having some control over who translates into what language, it's often a delicate process, since oneself cannot be the judge of "which translation is better and is this person right in claiming there is a problem with this translation?". I certainly myself don't know all the languages of the world, and even if I would, I wouldn't know it as good as a person who has the language as his mother tongue and spends much of his time translating into that language.

That's why a proper translation team divides its translators into language teams, to make the translators in the team (hopefully) collaborate and do some peer review on each other. In practice, this usually works out very well for improving translation quality and keeping a high quality over time.

Most of this is described at http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#use-a-tp , together with other good points.

Of course, to do this one needs to have a lot of translators that can be organized into groups, and that already have quite some experience in translating, and this essentially means using some existing translation project service. Reinventing the wheel is not good use of time, and neither is recruiting people and making them get together, when there are already projects that do that.

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. An important point of the GNOME Translation Project is that translators should easily be able translate many different pieces of software, and many of our translators also do. Also, many of the translators (at least one in each team, and many teams have many more than one) have CVS access themselves and are able to quickly commit their translations and translations for other members in their team, so the translations get really fast upstream.

And it only works because all translators work against the same CVS repository.

Granted, there are other translation projects as well. The Translation Project (http://www.iro.umontreal.ca/contrib/po/HTML/) is a translation project that serves as a translation service for many different software projects, and it doesn't rely on a central CVS repository or something like that. It's essentially a mail-based translation service, although it has all the benefits of language teams and so on behind the scenes.

Still, I think the GNOME Translation Project would be a better match, since Inkscape has connections to the rest of GNOME.

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.

So you wouldn't actually be losing a chance to change SCM tool by migrating to cvs.gnome.org. In fact, the change on gnome.org might perhaps even happen before Sourceforge would do it. However, it's a community decision.

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

and it doesn't correspond with our ultimate goal to move to Subversion anyway... So it's not entirely clear to me if this is worth the effort of doing. It might help to have a better idea of specifically how many GNOME developers/translators would contribute significantly to Inkscape if it was in GNOME CVS. I assume most people that wish to contribute to Inkscape would be able to just upload patches or request a CVS account from us.

We've also considered alternate bug trackers, but most people are suitably comfortable with the SourceForge tracker so there's no plans to change. I'm not sure what Bugzilla would buy us, other than imposing a more confusing user interface on our poor users. ;-) If we did change we'd probably adopt Mantis rather than Bugzilla.

Oh. We've had many projects move to GNOME Bugzilla just because they utterly detest Sourceforge's bug tracker and its lack of more advanced features so much. This is the first time I hear that someone likes it as it is. :)

Anyway, yes, Bugzilla is more complex. On the other hand, the GNOME bugmasters are constantly working on improving Bugzilla, and part of that is making it easier to report bugs: http://bugzilla.gnome.org/simple-bug-guide.cgi

Hint: Try to report a bug in the translation of a piece of software, say the Swedish translation of gedit. The bug report will be automatically assigned to a translator in the affected GNOME Translation project language team, in this case Swedish, so that he or she is immediately notified about the problem. Neat, isn't it?

Thanks for your comments, Christian

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

mån 2005-06-06 klockan 15:04 -0700 skrev Bryce Harrington:

On Sun, Jun 05, 2005 at 07:55:28PM +0200, Christian Rose wrote:

...

l?r 2005-06-04 klockan 19:44 -0700 skrev Bryce Harrington:

...

Judging from http://l10n-status.gnome.org/gnome-2.12/index.html, GNOME has 52 languages that have translation ratios over 50%.

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

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.

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

It sounds like a very effective process. The GNOME Translation Project appears to do very good work, and it looks like Inkscape could potentially pick up perhaps 20 more language translations. I would really like to find a way to work together, because it sounds like it would be in all of our benefit.

I spoke with several of the Inkscape developers, and unfortunately it seems there is not much interest in switching CVS providers. There would be strong interest in switching to a Gnome Subversion, though, if it becomes available. If we go through the process of changing sourcecode management systems, we'd like to do it just once, and going from CVS to CVS doesn't seem worth the trouble, even if it would eventually gain some more translators.

OK, it sounds like you've made up your mind now about this issue. I won't argue with that, just clear up some points raised below.

It sounds like many of our translators participate in both Inkscape and GTP already, so perhaps if having increased translations for Inkscape is important, in the interim before Subversion becomes available, you could make other translators aware of the need, and they could also choose to participate on a case by case basis if they wish.

...or we could wait until Inkscape finally has ended up in the GNOME repository, when the issue will automatically be solved. ;)

...

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.

Would you mind communicating Inkscape's interest in participating in this, if a decision is made and implemented? Also, if you could keep us informed of its progress that would probably help a lot.

Feel free to let the gnome-hackers@...45... list know that you would be willing to move to the GNOME repository, if it would be using Subversion. That's certainly relevant input to confirm that there actually needs to be a change.

gnome-hackers is a special list in the sense that it is a strictly moderated list, in order to reduce the amount of traffic and make sure that only relevant mails get through. It's not open for general subscription. The archives (http://mail.gnome.org/archives/gnome- hackers/) are open though, and you can get all mails posted to the list by subscribing to the gnome-hackers-readonly list (http://mail.gnome.org/mailman/listinfo/gnome-hackers-readonly) if you want.

That way, you would also be automatically notified when there would be a repository decision, I suspect.

...

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.

Well, keep in mind that a change would be disruptive, impose new risks, and would take time and effort to go through.

True.

I'm not sure how we'd preserve CVS history.

Oh, that one is simple. You would basically only need to decide on a date for the transition, hold off commits for a day or so, and then we'd import http://cvs.sourceforge.net/cvstarballs/inkscape-cvsroot.tar.bz2 (which is regenerated at least daily, I think) into GNOME CVS. That way, you would get all history preserved.

It sounds like we'd lose some ability to ensure people get CVS access quickly.

Yes, it might take some days to have all accounts done.

Developers would also have to redo their local trees and branches, to make them point at the new CVS. We don't know about the performance / stability of the Gnome CVS (we had problems with SourceForge early on, but things are much better today).

We've had no problems or complaints for the last year, at least not for the master CVS repository. One of the anoncvs mirrors located elsewhere in the world at one point got out of free disk space though, but that was quickly resolved when the local admins were notified about the problem. The other anoncvs mirrors still worked fine though.

We'd have to revise cron jobs and scripts that currently work on the SF CVS. We have some tools like our document generator that run on the SF web server, which can *only* access SF CVS, that we'd have to either rewrite or lose.

Good point.

So you can see that switching to Gnome CVS would impose transition costs. Since we'll have to do all this work anyway when we move to Subversion, I think the general feeling is, why do this work twice, if we can simply wait until Subversion becomes available?

Yeah, yeah, I hear you. I just would have hoped the transition to happen right now, instead of some (not yet decided) time in the future...

Ok, I'll shut up.

Christian

sön 2005-06-05 klockan 21:42 -0400 skrev MenTaLguY:

On Sat, 2005-06-04 at 22:44, Bryce Harrington wrote:

...

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?

One important question is whether switching to GNOME CVS would crimp our (relative to most projects, anyway) open-access CVS policy?

"Open-access" in what way? Are people getting CVS commit access just by asking, and without prior contribution? Or do you mean that they, after five years of continous substantial contributions to the project, don't have to sell one of their kidnies as well to gain access? ;-)

The requirements for getting a GNOME CVS account is basically that you must have your maintainer's approval, and that you can be trusted and really are in need of a CVS account (which again is why the maintainer needs to confirm it).

Christian

Just as Lucas Bruno says in his post to this same thread, I also do some Gnome translations and don't have any trouble with CVS access. The spanish GNOME team is coordinated by one person (or more, not really sure) that does the revision and commits packages to the CVS. The only missing part in the Inkscape translation process is the revision part, but I can't say it would be possible for someone to send a translation hat would overwrite mine because Arpad always assures that the new translator gets in touch with the old one.

By the way, I do the spanish translation of Inkscape GUI. ;)

El sáb, 04-06-2005 a las 19:44 -0700, Bryce Harrington escribió:

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?

...

...

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

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.

...

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

...

...

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.

...

...

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?

Bryce

---

This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel