Feature changed by: Michael Andres (mlandres) Feature #323785, revision 14 Title: generic translation of pattern-category Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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% 9F%BA%E7%A1%80%E6%8A%80%E6%9C%AF The translations come from a perl script in patterns-rpm-macros: https://build.opensuse.org/package/view_file/openSUSE:Factory/patterns-rpm-m... 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 description: https://l10n.opensuse.org/projects/packages-i18n/patterns-master/ Furthermore, how about instead of using this extra provides tag, use the rpm group tag, like e.g. Group: patterns/Base Technologies Discussion: #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 categories). 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. #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 + weblate? + 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. (#) -- openSUSE Feature: https://features.opensuse.org/323785