It sounds to me like we might be confusing database schema with
user workflow.
I agree with Bjorn’s points on what a typical volunteer
user workflow might look like, and the social ramifications arising from it.
But at the same time, hard-wiring into the schema that if a string
is changed for version X of a project that it would automatically and
irrevocably also be changed for version X-1 of a project sounds counter to good
software engineering practice. I think the schema itself should support a
unique mapping of string to version and we can have tool or workflow support to
define the scope of a new or modified string.
Or perhaps this is just another example of why email is a lousy
communications tool.
From: babel-dev-bounces@xxxxxxxxxxx
[mailto:babel-dev-bounces@xxxxxxxxxxx] On Behalf Of Bjorn Freeman-Benson
Sent: Monday, January 07, 2008 1:35 PM
To: Babel committers mailing list
Subject: Re: [babel-dev] Translations and Project Versions
I think this is a bad idea for two reasons:
- 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.
- 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.
