A proposal for the new roadmap 11.04
eagles051387 at gmail.com
Wed Oct 20 19:46:46 BST 2010
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
On Wed, Oct 20, 2010 at 6:11 PM, Valter Mura <valtermura at gmail.com> 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
> > > 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
> > > 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
> > > to Ubuntu, say "shared" files;
> > >
> > > #2 - Ubuntu-Gnome files: this branch would include only upstream
> > > files coming from the Gnome project plus upstream files containing
> > > possible changed strings;
> > >
> > > #3 - Kubuntu-KDE files: this branch would include only upstream
> > > files coming from the KDE project plus upstream files containing
> > > possible changed strings;
> > >
> > > #4 - Xubuntu-XFCE files: this branch would include only upstream
> > > 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
> for the main "Ubuntu Translation" branch.
> Replying to Tom's considerations, I think that also Kubuntu should be added
> 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.
> > 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:
> 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-
> - 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
> I think the good Launchpad developers will have no problems to integrate
> > > #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
> > > 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.
> Registered Linux User #466410 http://counter.li.org
> Kubuntu Linux: www.kubuntu.org
> OpenOffice.org: www.openoffice.org
> ubuntu-translators mailing list
> ubuntu-translators at lists.ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ubuntu-translators