Re: GNOME Moduleset Reorganization vs. L10N

[Dimitris Glezos <glezos indifex com>]

On Mon, Oct 18, 2010 at 1:12 PM, Kenneth Nielsen <k nielsen81 gmail com> wrote:
> The solution of having a translations only copy of a module in gnome
> git, combined with some sort of automatic syncing back and forth,
> seems to a good solution for the module maintainers that don't mind
> having this sort of solution.

I'm not sure how well this will work. The developer still needs to
sync between the trees, and in the past developers found this very
frustrating at times. An example is when a developer updates all PO
files with new strings and after this he pulls translations from the
translation branch. The merge is a nightmare (since git does a git
merge instead of a msgmerge).

The feedback we received so far is that viable solutions are two: a)
pull&push straight to the master branch and b) not push anywhere, just
"upload" the files somewhere and the developer will fetch them when he
needs to.

> In terms of translators this will mean
> that they can work the way they do now, so this should automatically
> be ok for translators*. Since it is almost an implementational
> freebie, is should be ok to have this as the base solution, and then
> after that determine if we want to add something else.
>
> So at this point, can we agree that this can be ONE acceptable
> solution? Then we could start working setting up the framework for it
> and actually implement it for the modules that are ok with it.

> Then we can afterwards continue discussing whether we should/need to
> add an offer for a external translation framework that is also GNOME
> approved (e.g. Transifex, Launchpad ,....).

I like this step-by-step, build-on-what-we-have approach, it's very
wise and I usually follow it as well. Admittedly, though, it has a
(serious) disadvantage: It only accepts solutions which can build on
top of the current way of doing things. This impedes real/radical
change. Sometimes radically changing things is good (e.g. when you're
in a dead-end).

Currently our way of working in GTP is "based on files hosted on a
VCS, namely git.gnome.org". The challenges are obvious and well
explained (although they hardly constitute a dead-end). My humble
suggestion is to take this opportunity to really think how effective
our way of doing things is. The plan behind Tx 1.0 was to move away
from "files hosted on a VCS" and go to "strings (not files) living in
a web app (not vcs) which can be imported/exported freely to files".
We had both independent projects as well as projects like GNOME behind
the decision.

It was a really, REALLY hard decision, but we are confident that it's
the way things will work in the future and the way to go. Things like
upstream/downstream support, translation memory, consistency,
per-string suggestions/voting.. they're all possible now. The Q is
whether we want to take this opportunity to really re-think how we're
doing things, or if we're just going to shift this decision to e.g. 2
years later. Sounds like a good BoF discussion for GUADEC. =)


Now, having said this, I just realized a potential issue with Tx &
GNOME. Tx 1.0 does NOT support intltool projects which do not have a
POT file. More information at the following pages:

http://help.transifex.net/user-guide/formats.html#intltool
http://help.transifex.net/user-guide/one-dot-zero.html#source-language-file-tracking

-d

-- 
Dimitris Glezos

Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/