Re: GNOME Moduleset Reorganization vs. L10N

[Kenneth Nielsen <k nielsen81 gmail com>]

2010/10/18 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. =)

Well, I agree that we should think hard and long about this at some
point, because we don't ever want to exclude ourselves from the
opportunity to make radical changes. But I really really really don't
think that the GNOME 3.0 cycle is the right time to do it.

Regards Kenneth