>
> 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
_______________________________________________
gnome-i18n mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-i18n
