Re: getting rid of kde-l10n
On Wednesday 03 February 2010 13:45:22 Stephan Kulow wrote: > Am Dienstag 02 Februar 2010 schrieb Rex Dieter: > > (1) releases that kept software/translations bundled together makes > > their packaging simpler, imo. > > And it makes translation much harder and it makes adding new languages > much harder. And it wastes quite some download time for users - that > usually only speak a small portion of the languages we offer. And I think it makes splitting out the translations necessary for LiveCDs with constrained space. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
Am Dienstag 02 Februar 2010 schrieb Rex Dieter: > (1) releases that kept software/translations bundled together makes > their packaging simpler, imo. And it makes translation much harder and it makes adding new languages much harder. And it wastes quite some download time for users - that usually only speak a small portion of the languages we offer. Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
A Dimarts, 2 de febrer de 2010, Helio Chissini de Castro va escriure: > On Tuesday 02 February 2010 17:41:43 Rex Dieter wrote: > > Hear me out. :) > > > > I'm not proposing anything yet, but would like to hear about the > > pros/cons of > > 1. status quo: shipping translations separately to software > > > > 2. shipping translations alonside (ie, in the same release tarballs) > > the software. > > > > How hard would it be to work toward something closer to 2 for KDE SC? > > > > -- Rex > > For me i see only one clear reason where this situation can provide some > benefits, if we go to git path to have per app repository. > Otherwise, change current structure is bad bad idea, nothing matter > pros/cons, is just change a secular ( yes, comes from last one :-) > process. > So i would advise to raise this question for l10n team and scm discussion. Moving the po files to the repository of each of the apps is the worst mistake you could make. Gnome had to write a whole web app just to overcome this problem in their repo. Albert > > []'s > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
On Tuesday 02 February 2010 17:41:43 Rex Dieter wrote: > Hear me out. :) > > I'm not proposing anything yet, but would like to hear about the > pros/cons of > 1. status quo: shipping translations separately to software > > 2. shipping translations alonside (ie, in the same release tarballs) > the software. > > How hard would it be to work toward something closer to 2 for KDE SC? > > -- Rex For me i see only one clear reason where this situation can provide some benefits, if we go to git path to have per app repository. Otherwise, change current structure is bad bad idea, nothing matter pros/cons, is just change a secular ( yes, comes from last one :-) process. So i would advise to raise this question for l10n team and scm discussion. []'s -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
On Tue, Feb 02, 2010 at 04:00:57PM -0600, Rex Dieter wrote: > On 02/02/2010 03:45 PM, Albert Astals Cid wrote: > > A Dimarts, 2 de febrer de 2010, Rex Dieter va escriure: > >> Hear me out. :) > >> > >> I'm not proposing anything yet, but would like to hear about the > >> pros/cons of > >> 1. status quo: shipping translations separately to software > >> > >> 2. shipping translations alonside (ie, in the same release tarballs) > >> the software. > >> > >> How hard would it be to work toward something closer to 2 for KDE SC? > > > > What would be the benefit? > > I know it's been this way for like forever. Just wondering what kinds > of attachments there are, and pros/cons of each approach. > > Honestly, part of this comes from my being a distro packager, but > keeping these separate is ... a bit painful(1). Also, fedora's release > team keeps asking my why kde keeps translations separate, and I honestly > don't have a good answer for them. > > Seems only the SC portions keep things separate, I mean extragear > releases bundle software/translations together, so it's not like it's > something new or different. > With my packager hat on, I only see benefits, and not only because you can provide translations updates without having to update anything else. This is useful specially when you distro is close to release and frozen. First, most of the users are only interested in translations of their own language(s) and the easiest is just install the package kde-l10-XX from their distro and get done with it. If you ship e.g. the kdeedu tarball with the translations, you have several options: - ship every app with their translations. This is not a big pain for packagers but it will make users have a lot of translations installed they are not interested in. - ship the translations in another package, per application (kdeedu-l10n) or per module (marble-l10n). Again you make users install translations they are not interested in and also have them installing several translation packages. Packages have here aditional work having to care for way more translations packages than before. - ship the translations in another package for every language: kdeedu-l10n-es, kdeedu-l10n-fr, etc. Again, more work for packagers and for users. - I will omit the possibility of translation package for application and language (marble-l10n-fr), because I think it is plain crazy. You could say that with the current approach, you have translations installed that you do not need if you use only a couple of KDE apps, but it seems a better approach installing 30 MB of translations for a couple of KDE apps that make KDE users install 600 MB of translations. The handling of extragears translation is not exaclty the way to follow here. In every release packager have to update the languages, and users in some cases do not know they have to install a translation for this package manually. For them, it is just another kde app... Said all this, could you tell me the benefits of shipping translations alonside? I just do not see any. Ana ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
On Tuesday 02 of February 2010, Rex Dieter wrote: > On 02/02/2010 03:45 PM, Albert Astals Cid wrote: > > A Dimarts, 2 de febrer de 2010, Rex Dieter va escriure: > >> 2. shipping translations alonside (ie, in the same release tarballs) > >> the software. > >> > >> How hard would it be to work toward something closer to 2 for KDE SC? > > > > What would be the benefit? > > I know it's been this way for like forever. Just wondering what kinds > of attachments there are, and pros/cons of each approach. > > Honestly, part of this comes from my being a distro packager, but > keeping these separate is ... a bit painful(1). Also, fedora's release > team keeps asking my why kde keeps translations separate, and I honestly > don't have a good answer for them. Why don't you ask them why it should be changed, and just stop there if they don't have a good answer? Why fix something that is not broken. > Seems only the SC portions keep things separate, I mean extragear > releases bundle software/translations together, so it's not like it's > something new or different. openSUSE actually bundles together even translations for some extragear stuff. And, as a user, I'll much rather install czech translations for few apps I perhaps don't use rather than translations for all the languages in the world I definitely do not use. > (1) releases that kept software/translations bundled together makes > their packaging simpler, imo. Why? You just package a tarball and that's it. What is there so complicated about that? -- Lubos Lunak openSUSE Boosters team, KDE developer l.lu...@suse.cz , l.lu...@kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
On 02/02/2010 03:45 PM, Albert Astals Cid wrote: > A Dimarts, 2 de febrer de 2010, Rex Dieter va escriure: >> Hear me out. :) >> >> I'm not proposing anything yet, but would like to hear about the >> pros/cons of >> 1. status quo: shipping translations separately to software >> >> 2. shipping translations alonside (ie, in the same release tarballs) >> the software. >> >> How hard would it be to work toward something closer to 2 for KDE SC? > > What would be the benefit? I know it's been this way for like forever. Just wondering what kinds of attachments there are, and pros/cons of each approach. Honestly, part of this comes from my being a distro packager, but keeping these separate is ... a bit painful(1). Also, fedora's release team keeps asking my why kde keeps translations separate, and I honestly don't have a good answer for them. Seems only the SC portions keep things separate, I mean extragear releases bundle software/translations together, so it's not like it's something new or different. -- Rex (1) releases that kept software/translations bundled together makes their packaging simpler, imo. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
A Dimarts, 2 de febrer de 2010, Rex Dieter va escriure: > Hear me out. :) > > I'm not proposing anything yet, but would like to hear about the > pros/cons of > 1. status quo: shipping translations separately to software > > 2. shipping translations alonside (ie, in the same release tarballs) > the software. > > How hard would it be to work toward something closer to 2 for KDE SC? What would be the benefit? Albert > > -- Rex > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
getting rid of kde-l10n
Hear me out. :) I'm not proposing anything yet, but would like to hear about the pros/cons of 1. status quo: shipping translations separately to software 2. shipping translations alonside (ie, in the same release tarballs) the software. How hard would it be to work toward something closer to 2 for KDE SC? -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
