Re: A proposal for the new roadmap 11.04
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 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
Re: A proposal for the new roadmap 11.04
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 ups
Re: A proposal for the new roadmap 11.04
Hi :) I would really like us to add Lubuntu to this list as it is likely to be made an official version soon. Xubuntu is getting too heavy to fulfill its market position as the light-weight Ubuntu because Xfce is quite heavy. LxDE is light enough to be used on very much lighter-weight machines such as people often have in attics or cupboards. If we finalise a set-up without considering Lubuntu then when it gets added we will have a bit of a messy interface. I thought we were aiming to centralise Ubuntu and just offer the other DEs as forks? Good luck and regards from Tom :) - Original Message From: Sveinn í Felli To: ubuntu-translators@lists.ubuntu.com Sent: Wed, 20 October, 2010 9:04:22 Subject: Re: A proposal for the new roadmap 11.04 Þann þri 19.okt 2010 22:45, skrifaði Valter Mura: > Hi All, > > 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 ? > 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). Possibly those definitions exist already in the database ? > #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-slideshow-ubuntu/+pots/ubiquity-slideshow-kubuntu/XX/+translate > #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. > #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. 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. I suppose "batch committing" would be a bit too much to ask for. > These are only some humble suggestions, I hope to contribute to improve the > system with these few ideas. > IMHO they're very useful. > By the way, I like very much the idea of an "Ubuntu Translation Portal"! :-) > > Ciao! Bless! Sveinn í Felli -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: A proposal for the new roadmap 11.04
Þann þri 19.okt 2010 22:45, skrifaði Valter Mura: > Hi All, > > 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 ? > 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). Possibly those definitions exist already in the database ? > #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-slideshow-ubuntu/+pots/ubiquity-slideshow-kubuntu/XX/+translate > #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. > #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. 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. I suppose "batch committing" would be a bit too much to ask for. > These are only some humble suggestions, I hope to contribute to improve the > system with these few ideas. > IMHO they're very useful. > By the way, I like very much the idea of an "Ubuntu Translation Portal"! :-) > > Ciao! Bless! Sveinn í Felli -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: A proposal for the new roadmap 11.04
On Wed, Oct 20, 2010 at 4:15 AM, Valter Mura wrote: > Hi All, > > 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. > --snip-- +1 Cheers Arjun -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
A proposal for the new roadmap 11.04
Hi All, 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. 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. #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). #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. #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." These are only some humble suggestions, I hope to contribute to improve the system with these few ideas. By the way, I like very much the idea of an "Ubuntu Translation Portal"! :-) Ciao! -- Valter Registered Linux User #466410 http://counter.li.org Kubuntu Linux: www.kubuntu.org OpenOffice.org: www.openoffice.org -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
