Feature changed by: Kai Dupke (kdupke) Feature #323785, revision 2 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? -- openSUSE Feature: https://features.opensuse.org/323785

Feature changed by: Michael Andres (mlandres) Feature #323785, revision 5 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. -- openSUSE Feature: https://features.opensuse.org/323785

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

Feature changed by: Michael Andres (mlandres) Feature #323785, revision 18 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. #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 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 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. (#) + #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. -- openSUSE Feature: https://features.opensuse.org/323785

Feature changed by: Ludwig Nussel (lnussel) Feature #323785, revision 20 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. #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 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 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. (#) #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: * https://github.com/openSUSE/inst-source-utils/pull/1 * https://github.com/openSUSE/instsource-susedata/pull/2 + #11: Ludwig Nussel (lnussel) (2018-10-30 16:38:51Z) (reply to #10) + One more thing, the actual package translations already include pattern + categories for translators to pick up: + https://l10n.opensuse.org/projects/packages-i18n/patterns-master/ -- openSUSE Feature: https://features.opensuse.org/323785