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