Re: Import from Launchpad

["Kenneth Nielsen" <k nielsen81 gmail com>]

You can more or less get the same effect temporarily by filtering
svn-commits-list if you tolerate the high volume.

But I understand this is frowned upon if many people do it because of
the bandwidth.

Djihed

Yeah it was done by filtering svn-commit-lists. And yeah I certainly understand that it is a bad idea if many people do it, which is why I think it is a good idea if it is done on a GNOME server and sent out centrally

> More so aggravated by the uncertainty we have with what the Rosetta
> developers want from Rosetta (Launchpad).
>
> At times we've been promised that upstream translations would be
> "locked", or that there would be some sort of mechanism to preserve
> upstream translations.
>
> Then some developers want the status quo because this makes it
> possible for launchpad translators to correct the odd 1 in 10000
> strings. Or because it makes it possible to continue translations. Now
> I don't know what they want any more.

You're not very fair, here. There has been new tools aimed to track
differences between upstream and downstream.
You can check the "Changed" column in your language package list in
Launchpad, which tells you how many strings have been modified from
upstream.
Then, in the package, you can filter all these strings ('Show:'
drop-down menu, 'changed in Launchpad') and compare the upstream and
changed strings. Then, you can either revert to upstream in two clicks
(if you have necessary rights), or use the string improvement in your
upstream file.

I think there is a lot more to it than that. In my belief Rosetta is simply not ready for serious collaboration with upstream yet, partly because that aspect has been neglected in favor of making the whole thing as newbie friendly as possible. I think this shows most clearly be evaluating its present state and comparing that to its age:
1) The "Changed" column you refer to only got patched to actually show the right numbers last month.
2) There still is no "clear" way to search for a singly (possibly erroneous) string inside a large translation or for a specific packages translation from a list.
3) There still is no cost(as in work)-efficient way to implement a proofreading procedure in such a way that the proposed translations are not committed until after proofreading (I know I know! I really should write a development specification for that one, but I'm simply don't currently have the time, and furthermore it is something that could have been anticipated if some study had been done into how upstream translation teams work)

> This is getting political, but I just hate this situation and I shake
> my head every time I see weird strings in ubuntu GNOME interfaces.

We have very good relationship in French team between upstream and
Ubuntu translators, and all is going pretty well now.
Like in many other stuff, it's a more a matter of establishing
relationship than technical or political problems.
Peopleware! :-)

As someone else replied, small languages don't always have the resources. But actually for the Danish translation it is the same group if people, and the main reason it does not work properly is because Rosetta is simply to clumsy for our way of working.

> +1 from me.

from me also

> Anyway, we need some general agreement here and then we
> should discuss this with Ubuntu in some offical way (e.g. through GNOME
> Foundation). In general cooperation with Ubuntu seems to be quite good
> and they are also pushing GNOME forward a lot and we should really
> coordinate this point!
Indeed collaboration is better that complaining, besides getting a official request from official GNOME channels might get things moving ;)

Regards Kenneth Nielsen