Bug 261094 - Provide proper l10n tarballs
Summary: Provide proper l10n tarballs
Status: RESOLVED NOT A BUG
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Dirk Mueller
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-23 18:53 UTC by Johannes Obermayr
Modified: 2010-12-24 00:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Obermayr 2010-12-23 18:53:46 UTC
Version:           unspecified (using Devel) 
OS:                Linux

Decision was kdepim 4.6 won't be delivered.
It should be used KDE 4.6 together with kdepim 4.4.x.

So provide proper l10n tarballs:
- translations for kdepim from /branches/KDE/4.4/kde-l10n/*/{docmessages,messages}/kdepim
- translations for all other modules from /branches/KDE/stable/l10n-kde4/

Reproducible: Always
Comment 1 Pino Toscano 2010-12-23 21:32:02 UTC
Wouldn't be quite more logic to just provide l10n tarballs for kdepim 4.4.x alone?
Comment 2 Johannes Obermayr 2010-12-23 21:51:55 UTC
Nope.
openSUSE for example builds one l10n package per language:
https://build.opensuse.org/package/files?package=kde4-l10n&project=KDE%3ADistro%3AFactory

https://build.opensuse.org/package/binaries?package=kde4-l10n&project=KDE%3ADistro%3AFactory&repository=openSUSE_11.3

I assume other distributions also provide only one package containing all translations of main modules per language ...

It is a mess adjusting each time the build script because kdepim developers do not know what they want.

So it is right providing l10n packages as I described above ...
Comment 3 Pino Toscano 2010-12-23 22:59:32 UTC
No, sorry, I don't see the logic to ship a l10n tarball containing most of translations for kde 4.6, with a module having kde 4.4 translations, as opposed to having a quite more logical split reflecting the kde 4.6 release:
- given kdepim is not part of kde 4.6, the l10n tarballs for it should NOT contain kdepim at all
- provide separate l10n tarballs containing ONLY kdepim 4.4.x translations, to be used when shipping the kdepim 4.4.x sources

This way, you would have kde-l10n-xx 4.6.x modules containings translations for all the kde modules except kdepim, and kdepim-l10n-xx 4.4.x containing only kdepim translations.
Comment 4 Johannes Obermayr 2010-12-23 23:32:39 UTC
Since KDE releases are a compilation (of the main modules - kdepim is one of them) the right way would be:

pushd kdepim
git checkout origin/4.4
git tag -a v4.6.0 -m "Tag/Release v4.6.0"
git archive tags/v4.6.0 --prefix=kdepim-4.6.0/ | bzip2 --best >../kdepim-4.6.0.tar.bz2
popd

And then provide the translations as mentioned above with main l10n tarballs.

But I know: A logical conclusion is not what KDE does each time ...
Comment 5 Pino Toscano 2010-12-24 00:09:48 UTC
(In reply to comment #4)
> Since KDE releases are a compilation (of the main modules - kdepim is one of
> them) the right way would be:
> [...]

No, that is just wrong.
There is no rationale for shipping translations with kde 4.6 for modules that are NOT part of kde 4.6. As of kde 4.6.0rc1, there's no kdepim shipped, so it is logic that the translations for kde 4.6.0 do not include kdepim.

Your way of doing of doing stuff is just because you think a single source tarball for translations should fit everything, which is not correct -- as I said above, two tarballs (one for what is in kde 4.6.0, and one for what is in kdepim 4.4) can just do the job fine.
What you would want would be logical only if we would ship kdepim 4.4 as part of kde 4.6, which is not what we do.

Anyway, this discussion does not belong at all to bugzilla. Please email the release-team ml, which is the proper place for this discussion.
Comment 6 Johannes Obermayr 2010-12-24 00:42:40 UTC
Just to clarify:

http://techbase.kde.org/Policies/SVN_Guidelines

The diagram there and situation with kdepim since pre-4.5 shows me that kdepim must be moved to extragear (may playground) ...
Then your conclusion/solution is right.
Otherwise a kdepim version must be released with KDE release.

But as you said the first part is not a discussion for bugzilla.