i like these ideas as well. is there a way version control can be done on the packages that way any string changes can be merged into one centralized package?<br><br><div class="gmail_quote">On Wed, Oct 20, 2010 at 6:11 PM, Valter Mura <span dir="ltr"><<a href="mailto:valtermura@gmail.com">valtermura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">In data mercoledì 20 ottobre 2010 10:04:22, Sveinn í Felli ha scritto:<br>
<div class="im"><br>
> > with regard to the latest announcement made by David in the list, I would<br>
> > like to submit to you my humble ideas about a new structure for Ubuntu<br>
> > translations in Launchpad.<br>
> ><br>
> > The idea is very simple: splitting the Ubuntu translation structure from<br>
> > one single branch into, at least, 4 branches with eventual derivative<br>
> > sub- branches. The reason is to have a more rational structure in which<br>
> > translators can easily individuate and manage packages to translate.<br>
> ><br>
> > I think also that a new structure will facilitate the work of the<br>
> > translators and speed up the translation process.<br>
><br>
> Great work - I second these. We're talking about the<br>
> organisation of the translation interface, isn't it ?<br>
<br>
</div>Yes, of course, and documentation, too.<br>
<div class="im"><br>
><br>
> > Here is a possible subdivision:<br>
> ><br>
> > #1 - Ubuntu-files: this branch would include language files related only<br>
> > to Ubuntu, say "shared" files;<br>
> ><br>
> > #2 - Ubuntu-Gnome files: this branch would include only upstream language<br>
> > files coming from the Gnome project plus upstream files containing<br>
> > possible changed strings;<br>
> ><br>
> > #3 - Kubuntu-KDE files: this branch would include only upstream language<br>
> > files coming from the KDE project plus upstream files containing<br>
> > possible changed strings;<br>
> ><br>
> > #4 - Xubuntu-XFCE files: this branch would include only upstream language<br>
> > files coming from the XFCE project plus upstream files containing<br>
> > possible changed strings.<br>
><br>
> This could be a simple drop-down field above the file list;<br>
> with options like<br>
> all/Ubuntu_shared/Ubuntu_GNOME/Kubuntu_KDE/Xubuntu_XFCE (and<br>
> maybe an Undefined field for modules early in the<br>
> translation cycle).<br>
<br>
</div>In that way, you need to add a "tag" to indicate which branch<br>
the package belongs to.<br>
<br>
On the contrary, the other structure would imply the creation of sub-branches<br>
for the main "Ubuntu Translation" branch.<br>
<br>
Replying to Tom's considerations, I think that also Kubuntu should be added to<br>
the list, if the project becomes stable and coordinated with the others.<br>
<div class="im"><br>
> Possibly those definitions exist already<br>
> in the database ?<br>
<br>
</div>I don't know.<br>
<div class="im"><br>
><br>
> > #5- For 2, 3, 4 files there should be also indication of original<br>
> > (upstream) URL, and possibility to have e-mail notification of changes<br>
> > in the files (this applies also to #1).<br>
><br>
> This could be in the header of the initial translation page,<br>
> e.g.<br>
> <a href="https://translations.launchpad.net/ubuntu/maverick/+source/ubiquity-slidesh" target="_blank">https://translations.launchpad.net/ubuntu/maverick/+source/ubiquity-slidesh</a><br>
> ow-ubuntu/+pots/ubiquity-slideshow-kubuntu/XX/+translate<br>
<br>
</div>No, I was thinking to simply put an URL inside the Launchpad page of the<br>
translation, something like: "the upstream package can be found here:<br>
address_of_the_package"<br>
Note: I would put the URL for the localized package and also the URL of the<br>
upstream translation team.<br>
<br>
For what I'm concerned - an example for my loved program "KPackageKit" :-) :<br>
<br>
- upstream URL repository: <a href="http://websvn.kde.org/trunk/l10n-" target="_blank">http://websvn.kde.org/trunk/l10n-</a><br>
kde4/it/messages/playground-sysadmin/kpackagekit.po<br>
- Italian KDE Translation Team: <a href="http://kde.gulp.linux.it/" target="_blank">http://kde.gulp.linux.it/</a><br>
<br>
In this case, its upstream position can vary, because it is placed in<br>
"playground-sysadmin", so it's a temporary position.<br>
<br>
There could be also a check box like "Watch this package", in case the<br>
translator would want to keep an eye to version updates.<br>
<div class="im"><br>
><br>
> > #6- For upstream files, there could be also a note indicating the<br>
> > "upstream" situation of the file, for example, if the file is contained<br>
> > in a stable or unstable/trunk branch.<br>
><br>
> And maybe having the date of last synchronization with<br>
> upstream would be of use.<br>
<br>
</div>Yes, the importing from CVS, SVN and GIT is already setup and is working well,<br>
I think the good Launchpad developers will have no problems to integrate it.<br>
:-)<br>
<div class="im"><br>
><br>
> > #7- Release cycles should be coordinated with the release ones of the<br>
> > upstream work-flows. To clarify this point: the release of a language<br>
> > update must be done only after the release of the upstream. This seems<br>
> > to be logical, but often it isn't, above all if packs are taken from<br>
> > both branches indicated in #6. Language packs are often incomplete, if<br>
> > the upstream way is not followed. This involves also the work in<br>
> > Launchpad, which could vanish after an upstream update. In this way,<br>
> > translators who work on an "upstream<br>
> > (untranslated/partially untranslated) package" could notify directly the<br>
> > translator in charge, thanks to #5: "Hey, I translated the file you are<br>
> > working on, I'll send it to you so that you could give it a look and<br>
> > use, if you wish."<br>
><br>
> In a previous thread, there was some discussion about having<br>
> a lang-pack-bugfix upgrade relatively soon after a release<br>
> (eliminating the most apparent errors) and maybe another<br>
> intermediate one (before next 6 monthly release).<br>
> If this can also coincide with upstream releases, good.<br>
<br>
</div>Yes, and if Launchpad release were a week after the upstream release, this<br>
would be perfect for Launchpad translators<br>
<div class="im"><br>
><br>
> And may I add:<br>
><br>
> #8- If translators (reviewers/coordinators) could easily<br>
> download all the POs of their language in one go, that would<br>
> be nice.<br>
<br>
</div>Yes, but probably this is a technical issue.<br>
<div class="im"><br>
Ciao<br>
--<br>
Valter<br>
Registered Linux User #466410 <a href="http://counter.li.org" target="_blank">http://counter.li.org</a><br>
Kubuntu Linux: <a href="http://www.kubuntu.org" target="_blank">www.kubuntu.org</a><br>
OpenOffice.org: <a href="http://www.openoffice.org" target="_blank">www.openoffice.org</a><br>
<br>
--<br>
</div><div><div></div><div class="h5">ubuntu-translators mailing list<br>
<a href="mailto:ubuntu-translators@lists.ubuntu.com">ubuntu-translators@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jonathan Aquilina<br>