Translation ownership and rights is one the things that we will have to
think most in the specs, as this might change a lot from team to team.
We have not yet specificed much about this in WordForge
There is one traditional path of localisation that is usually followed
in proprietary software and content (translate-review-approve), but it
not at all unique. In this case the committer is the "approver", but in
some others the translator is the committer, and the reviewers are only
consulted.
The jobs (in the translation team side) seem to be clear (please add to
the list if you can think of more): translator, reviewer, Translation
Manager (approver?), terminology manager.
The rights or permissions can also be defined (committing, uploading,
approving new terminology, etc...).
What we need to specify are the translation processes that we have to be
open to, and - in each one of these processes - which rights are given
to each participant.
A flexible application would allow a team to chose a process, assign
rights to each type of participant and to decide which type of
participant can delegate rights (admit) other types of participants.
Should only the Translation manager allow new people in?... or can a
reviewer accept new translators?... or a translator accept new
reviewers?. There are a large number of things that need to be left
open, in order to be very flexible.
The system needs to be flexible... but have a lots of defaults for new
teams or small teams not to get lost in customizing what they need.
Other parts of the specs are quite straight forward, or technical
decision, but this is the one that will make the system acceptable to
existing Debian localisation teams or not.
Javier
cobaco (aka Bart Cornelis) wrote:
On Saturday 20 May 2006 15:05, Gintautas Miliauskas wrote:
Hello,
The slides we used during the 2nd BOF of Debconf about i18n
infrastructure are available at:
http://people.debian.org/~bubulle/i18n/debconf6-bof2.pdf
Great job. It's already a bit difficult to keep everything in my head,
I just want to get started with the backend and see how things work
out ;)
I am still not sold on the 'translation owner' idea, I think that would
be too rigid. Of course, this can be made configurable.
the concept of 'translation owner' is central to the way
(debian)-translation works:
- translation is not an exact science and personal elements like style do
come in to it
- having lots of people directly messing with 1 translation is just not a
good idea as it produces mixed style translations (kinda how wikipedia
articles often aren't al that cohesively written, even though all the info
is there)
- a review comments coupled with sane orphaning/hijacking procedures really
give you all the good points of people being able to contribute easily,
without the headackes of different people directly messing with the same
translation
- having more then 1 translator isn't all that necessary for most
debian-specific translations (a single debconf-po file with more then 100
strings is uncommonly big, and the few bigger translations like apt, dpkg
and aptitude, don't move all that fast)
NOTE: this might very well be different for big translations of program
interfaces especialy when the program development, and amount of
updates needed moves fast
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
