Mailinglist Archive: opensuse-features (11 mails)

< Previous Next >
[openFATE 323785] generic translation of pattern-category
Feature changed by: Ludwig Nussel (lnussel)
Feature #323785, revision 19
Title: generic translation of pattern-category

Requested by: Ludwig Nussel (lnussel)
Partner organization:

pattern packages have special tags for the category, e.g.
pattern-category() = Base%20Technologies
Also, translations are contained directly in the package, ie
pattern-category(de) = Basistechnologien pattern-category(zh_CN) = %E5%
The translations come from a perl script in patterns-rpm-macros:
Ie not via weblate. Also putting localized strings in package metadata is
uncommon on (open)SUSE.
So instead of using a custom special method we should use the regular
package metadata translation mechanism we also use for summary and
Furthermore, how about instead of using this extra provides tag, use the rpm
tag, like e.g. Group: patterns/Base Technologies

#1: Kai Dupke (kdupke) (2017-08-08 07:15:35Z)
Is openSUSE using the l10n aproach?

#2: Ludwig Nussel (lnussel) (2017-08-25 07:51:12Z) (reply to #1)
opensuse uses weblate for almost everything related to translations,
yes. patterns is one of the few remaining issues.

#3: Michael Andres (mlandres) (2017-08-25 08:51:22)
Pattern and Product are virtual objects. Their properties are derived
from an associated physical package (patterns-* or -release packages).
Pro of this approach is that even if you'd manipulate your system rpm-
only, zypp will always properly recognize the installed Patterns and
Products. Neither within a repo nor within an installed system we need
extra metadata files for them. Also a big plus for SUMA/SCC/... because
they don't need to be aware of the 'extra matadata' the task packages
ship. No extra files. No extra parser. No extra metadata generator.
Please remember SLE11 time, where we used extra metadata files for
patterns and products. The inability to reliably determine the
installed patterns/products, to properly remove or update
patterns/products. We do not want this back, nor do our customers.
Kind of 'Con' of course is the fact that the associated task packages
need to ship the Pattern/Product attributes within their metadata,
usually within the task packages 'provides' (like e.g. the translated
Shifting the location of individual tags would be possible provided
they are still part of the task packages rpm header, i.e. available in
the rpm database and in the repositories primary.xml. Disadvantage
however is thet older zypp versions will not recoignize thes tags. This
may raise issues for the migrations.

#8: Ludwig Nussel (lnussel) (2018-08-16 08:22:50Z) (reply to #3)
I think it would make sense to use susedata.xml to add a "pattern-
category" with language, just like it's done for summary, eg.
<pattern-category lang="de">Advanced Systems Management</pattern-
In the spec file resp rpm itself the existing pattern-category()
provides can stay

#4: Simon Lees (simotek) (2018-04-04 14:00:11)
It turns out that the public cloud and a couple of the other smaller
SLE addon patterns were already doing this and integrating into the old
svn translation system. Ill look at updating everything else to do
something similar.

#7: Michael Andres (mlandres) (2018-08-10 08:11:09)
So how should this look like in the future, and how is ZYPP involved?
From the ZYPP POV:
The libzypp API offers to retrieve the category in an arbitrary
language (defaults to the current locale, fallback `en`). That's why
we'd prefer to have access to all available translations.
OTOH I doubt that there is actual need to retrieve languages other than
the current locale (zypper,PK don't do this, don't know about YAST but
can not imagine where).
So we could think about switching to retrieve the category translation
via gettext, if they will no longer be made available in the rpm
package header! (translations in extra metadata files will lead to
untranslated category strings for installed patterns).
@Ludwig: The question is how to access the translations? Shall we
maintain a category list in libzypp, and let them being translated via
The second issue, using the rpm group tag rather than pattern-
category(), must be negotiated with Michael Schroeder, he owns the
parser code. But I don't think it would be too hard to use the category
as fallback if pattern-category() is missingg. (#)

#9: Michael Andres (mlandres) (2018-10-30 13:04:56)
@Ludwig, Michael S.: Are we going to tackle this? AFAICS the SLE15SP1
repo matdata still define the category translations within the pattern-
packages provides and not in susedata-LANG.xml.
In case of doubt, we should update the Developers roles. The feature is
more about the repo metadata generator (?) and might require adapting
the libsolv parser accordingly (mlschroe?). But nothing needs to be
done within libzypp.

+ #10: Ludwig Nussel (lnussel) (2018-10-30 14:06:13Z) (reply to #9)
+ Ok, so let's try to break this deadlock somehow:
+ *
+ *

openSUSE Feature:

< Previous Next >
List Navigation
This Thread