Re: [babel-dev] Translations and Project Versions

[Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>]

Title: New Page 1

I think this is a bad idea for two reasons:

1. If contributor X is working on the strings for version X of project P and finds a bug in one of the strings (string M), she will fix it. Unless there is a database mechanism that links the string M of version X of P to string M of version X-1 of P, none of the previous version's strings will be updated. That's reality.
2. More seriously, how do we deal with overlapping project development schedules? Consider the following situation:

Project P is working on version 2.0 of their code this year. The Babel server is showing version 2.0 of their plug-ins for translation. Contributors are contributing strings towards version 2.0.

Then, in April, project P starts a version 3.0 branch. The Babel server automatically picks this up and now defaults to version 3.0 for people who are doing translations. Version 2.0 is not done and nobody is going to go back and work on version 2.0. Volunteers want to work on the latest thing, so unless we have a way to link the 3.0 work to the 2.0 strings, the 2.0 work will never get finished. That's reality.

I guess you might say "don't show version 3.0 until version 2.0 is finished", but that's not going to work either because there are people who need to work on 3.0 earlier.

To me the only solution is to have the 2.0 and 3.0 strings linked.
------------------------------------
I think the problem here is that we don't have a good written description of the expected user interactions. In fact, I am beginning to believe that the user interactions I believe are going to happen (volunteers working on translations piecemeal and in their spare time) is not the same as the user interactions that Kit believes are going to happen (professionals working on translations in batches?). We, the Foundation, are not building tools for the professionals here - we are building tools for the volunteers. So we need to face the reality of the volunteer user patterns.

- Bjorn

Denis Roy wrote:

As per todays' call, I'm not sure we all agree with the project/version layout that is suggested below.  As Kit mentioned, his design idea calls for each version to have its own set of translatable strings, with the import process dealing with the merge. Kit's idea also allows for newer versions to drop strings that were there in past versions.
My vote is to leave the project/version/string setup as-is: each version with its own set of translatable strings.

--
[end of message]