Localization of custom value tags in AppStream data

Ingo Klöcker kloecker at kde.org
Thu Jun 29 11:22:39 BST 2023


On Mittwoch, 28. Juni 2023 23:28:20 CEST Albert Astals Cid wrote:
> El dimecres, 28 de juny de 2023, a les 11:08:41 (CEST), Ingo Klöcker va
> escriure:
> > what would need to be done to localize the custom value tags in AppStream
> > data?
> > 
> > The concrete use case is adding Windows-specific screenshots including
> > captions as custom value tags to AppStream data. See
> > https://invent.kde.org/network/neochat/-/merge_requests/1053
> > for an example and more details on the why.
> > 
> > I know that the JSON-converter for the AppStream data (used for
> > apps.kde.org) would need to be changed. I suppose the script that extracts
> > the strings to translate also needs to get support for custom values.
> > 
> > Would it make sense to mark translatable custom values somehow, so that
> > only those are extracted? Maybe with xml:lang="C"? Or xml:lang="en"?
> 
> See
> https://invent.kde.org/sysadmin/l10n-scripty/-/blob/master/extract_metainfo.
> sh and
> https://invent.kde.org/sysadmin/l10n-scripty/-/blob/master/as-metainfo.its

Thanks. Okay, marking the custom values for translation by adding xml:lang="C"
doesn't work because the extraction script first removes any nodes with the
xml:lang attribute (to get rid of existing translations).

As example, let's assume I want to extract the values of the following nodes
for translation:
  <custom>
    <value key="KDE::windows_store::screenshots::1::caption">Bla bla</value>
    <value key="KDE::windows_store::screenshots::2::caption">Foo bar</value>
    [...]
  </custom>

One solution is extending the list of nodes to extract specified in 
as-metainfo.its, e.g. by adding the selector
  /component/custom/value[contains(@key,'::caption')]
to match custom values with keys like
  KDE::windows_store::screenshots::1::caption
  KDE::windows_store::screenshots::2::caption
Pity that XPath 1.0 has starts-with() but not the needed ends-with(), so
that I had to use contains().

Alternatively, multiple selectors matching exactly one key each could be added
  /component/custom/value[@key='KDE::windows_store::screenshots::1::caption'] |
  /component/custom/value[@key='KDE::windows_store::screenshots::2::caption'] |
  [...]
but that feels rather verbose and tedious.

A more general approach would be to use special keys for translatable
custom values, e.g.
  <custom>
    <value key="KDE::windows_store::screenshots::1::caption::i18n">Bla bla</value>
    <value key="KDE::windows_store::screenshots::2::caption::i18n">Foo bar</value>
    [...]
    <value key="KDE::windows_store::VoiceName::i18n">Bar bar</value>
  </custom>
and extract those with the selector
  /component/custom/value[contains(@key,'::i18n')]

But, if we anyway need to mark translatable custom values in the source files,
then we could probably also do this
  <custom>
    <value key="KDE::matrix">#foobar:kde.org</value>
    <value key="KDE::windows_store::screenshots::1::caption" its:translate="yes">Bla bla</value>
    <value key="KDE::windows_store::screenshots::2::caption" its:translate="yes">Foo bar</value>
  </custom>
i.e. explicitly add the attribute its:translate="yes" to custom values that
should be translated.

Which approach would you prefer? Concrete-contains-selector(s)?
Spelled-out-list-of-keys-selectors? Generic-contains-selector?
Marking-for-translation-in-source-file?

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20230629/58f7bf84/attachment.sig>


More information about the kde-i18n-doc mailing list