Re: Gutsy translations now open!
> That feature is indeed very good news. It is a little unclear from the > earlier posts how it will work, but PLEASE make it possible to do for en > entire package with one click, as i don't much care for pressing 'next' 460 > times going through the evolution package (or in any other way doing it > manually per string) ;) Actually, you'll have to do that, and that's on purpose. We still want to keep ability to modify strings coming from packages, and having a one-click option would encourage ignoring those translations which indeed have problems. However, note that once you revert the string, it will continue getting updates from upstream without the need to re-revert it again. Well I don't know how to respond to that. For the Danish language we do ALL GNOME and KDE translations upstream and therefore the LP team is a subset of the upstream teams whose only job is to fix integrations problems and translate Ubuntu specific packages. Furthermore whenever we are informed of an error we fix it both places (LP and upstream) as soon as it is possible. This means that the hypothetical situation you mention above (if the change you mentions refers to an error that gets fixed) simply doesn't exist. And those two projects in them selves are something like 60-70.000 strings, so thats a lot of "next"s that could be spared. That fact that we have problems now is of course our doing because we didn't close the LP-group the first chance we got (stupid us :) ). But I must say that I don't think that it is something that will do wonders for the already problematic Ubuntu-LP/upstream translation-relations that you, by policy, will be forcing translators to waste time on something like this, even if it is a one time thing. All things considering I think that time could be used in a better way on something like . well actually translating something. Please forgive me if I sound harsh, that is not my intention, but it just that the entire LP/Rosetta experience have been very frustrating (not being able to search for translations or strings in translations and these problems with imporrt/export and functionality and priority) for a lot of people that want to help, and now when it gets fixed it still doesn't really solve the problem in a satisfactory way. Oh well. Could I suggest then that it could be made possible to filter for these strings (the ones that are different from upstream), so that we wont have spend to much time doing this kind of trivial work? I have another question that in some way relates to this. The advantage of > large exposure of prerelease upstream translations depend very much on > regular/scheduled/dependable integrations of upstream translations. The last > time I asked (which is quite some time ago) such > regular/scheduled/dependable integrations had hot yet been accomplished, > have they been accomplished now? And in that case where can I read about the > integration schedule and/or rutine? I know how it works for GNOME and Ubuntu: they are integrated whenever GNOME modules have a release, or at the very least, when GNOME does a full release (eg. 2.19.1 on April 23rd, .2 on May 16th, .3 on June 6th, .4 on June 20th, .5 on July 11th, .6 on August 1st, then beta 1 on August 15th...), so at most 3 weeks between syncs. However, packaging GNOME modules usually takes between 1 and 5 days, so you should delay all those dates by that much. Ok thanks a lot. That is very helpfull. Regards Kenneth Nielsen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Gutsy translations now open!
Hi Kenneth, Today at 12:27, Kenneth Nielsen wrote: > That feature is indeed very good news. It is a little unclear from the > earlier posts how it will work, but PLEASE make it possible to do for en > entire package with one click, as i don't much care for pressing 'next' 460 > times going through the evolution package (or in any other way doing it > manually per string) ;) Actually, you'll have to do that, and that's on purpose. We still want to keep ability to modify strings coming from packages, and having a one-click option would encourage ignoring those translations which indeed have problems. However, note that once you revert the string, it will continue getting updates from upstream without the need to re-revert it again. > I have another question that in some way relates to this. The advantage of > large exposure of prerelease upstream translations depend very much on > regular/scheduled/dependable integrations of upstream translations. The last > time I asked (which is quite some time ago) such > regular/scheduled/dependable integrations had hot yet been accomplished, > have they been accomplished now? And in that case where can I read about the > integration schedule and/or rutine? I know how it works for GNOME and Ubuntu: they are integrated whenever GNOME modules have a release, or at the very least, when GNOME does a full release (eg. 2.19.1 on April 23rd, .2 on May 16th, .3 on June 6th, .4 on June 20th, .5 on July 11th, .6 on August 1st, then beta 1 on August 15th...), so at most 3 weeks between syncs. However, packaging GNOME modules usually takes between 1 and 5 days, so you should delay all those dates by that much. So, in essense, this depends on how often does Ubuntu package relevant modules which include updated translations from upstream. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Gutsy translations now open!
Hello everybody Basically, most of the problem we have now is due to previous changes to upstream translations, and that will be solved with the ability to revert more easily in the 1.1.6 release of Launchpad, due at the end of June. That feature is indeed very good news. It is a little unclear from the earlier posts how it will work, but PLEASE make it possible to do for en entire package with one click, as i don't much care for pressing 'next' 460 times going through the evolution package (or in any other way doing it manually per string) ;) I have another question that in some way relates to this. The advantage of large exposure of prerelease upstream translations depend very much on regular/scheduled/dependable integrations of upstream translations. The last time I asked (which is quite some time ago) such regular/scheduled/dependable integrations had hot yet been accomplished, have they been accomplished now? And in that case where can I read about the integration schedule and/or rutine? Regards Kenneth Nielsen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Gutsy translations now open!
Hi Claude, Jannick, Yesterday at 17:36, Jannick Kuhr wrote: > Am Dienstag, 12. Juni 2007 schrieb Claude Paroz: >> I don't know if this is really a good idea, as GNOME didn't even enter >> string freeze... >> >> Please, team leaders, warn your translators not to touche GNOME (and >> possibly KDE) strings, at least until GNOME 2.20 is out ! > > I have exactly the same doubts regarding this issue. Probably it would be the > best to lock KDE and Gnome translations for the first months. There are teams doing translations directly in Launchpad, even for KDE and GNOME, and then submitting them upstream. It would be a very bad idea to actually push them away from Launchpad, at least from our POV. > It is a VERY bad idea to import beta versions of programs to Rosetta. Please > lock this apps until the upstream translation process is finished! Not really: this actually means that with enough discipline (i.e. not going around and randomly translating stuff in Ubuntu Gutsy po files), even upstream translators can benefit: latest translations from KDE/GNOME packages will get into Gutsy, and Gutsy language packs, which will now be available on a daily basis from official repositories. So, you could easily say goodbye to GARNOME, jhbuild for GNOME (there's probably something similar which builds KDE from SVN or tarballs), and just use Ubuntu Gutsy to test how your translations look. > I am working for the german KDE translation team on the translation of > KTorrent. Now I had to see that a beta version of this app has been imported > to Rosetta with a lot of untranslated stings. This will result in a fork of > the translation and lost efforts on both sides. It makes me a little bit sad > to see that a reasonable cooperation and coordination between upstream and > Ubuntu still does not exist. This is a different problem: we haven't encouraged enough cooperation between Ubuntu translation teams and upstream teams. Basically, this would be the same problem that happens in upstream teams: two people start translating a single PO file without letting each other know, so we end up with wasted work. Here it's only more pronounced because of the larger "distance" between the teams. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
