Handling translations

[larshp]

No description provided.

[schneidermic0]

Let me try to summarise the current (not final) approach.

1. .abap files do not contain translation relevant content
2. Files containing structured data (.json) indicate their originalLanguage and consist of shortext descriptions or domain relevant texts (like the text for a domain value, or the message text in a message class) in the .json file.
3. Text symbols are not part of the .jsonand are exported as .properties with an addition to the filename to indicate which language the texts are. This file could be taken 1:1 with another language and only language-relevant parts have to be updated. An example can be found here

It is still open how to add translations of texts that are part of the .json file or how other translatable artifacts are handled (like documentation; see #130)

[schneidermic0]

I just add a link to a POC which tries to handle abapGit translations:
https://github.com/sbcgua/abapgit-translation-poc

[albertmink]

Pull from remote with changed language does nothing

[larshp]

SCP1 contains translations, https://github.com/SAP/abap-file-formats/blob/main/file-formats/scp1/type/zif_aff_scp1_v1.intf.abap#L133-L149

[schneidermic0]

Here just some links to translation relevant topics in abapGit:

• Translations concept abapGit/abapGit#2539
• Question: how to separate translations from code? abapGit/abapGit#1886
• abapGit: Make exception text messages and screen texts translatable abapGit/abapGit#2368

[schneidermic0]

I have created two examples how translation cloud look like. Both are no final propsals. They are meant for further discussion

• Using same JSON structure as original ABAP file formats JSO files. See WIP: Idea for handling of translations: Using same JSON structure for translation files #510
• Using .properties files. See WIP: Idea for handling of translations: Using properties files  #511
  This approach is kind of similar to Translations concept abapGit/abapGit#2539.
  Difference is one file per object and language instead of all translations in one file per repository.

[schneidermic0]

I had a meeting with a colleague from SAP who is responsible/working on LXE tools for ABAP. His preference would be properties files because SAP's non-ABAP artifacts (like Fiori or Java) are also using properties files for their translation processes.

[albertmink]

👋 Hi there 👋
Over the last months abapGit moved into the direction of .po files (still experimental see abapGit/abapGit#6189 ) and as we had also quite a view offline discussions, it's time for a quick status update.

We try to decide between .po and .properties file format (we dropped the .json based format).

Examples:
Assume we have translation relevant texts in a typical AFF file (text elements for CLAS are in a different AFF file and there will be more objects that store translation relevant parts in other files 😢 )

{
  "formatVersion": "1",
  "header": {
    "description": "day",
    "originalLanguage": "en"
  }
}

PO file:

#: header.description
msgid 'day'
msgstr 'Tag'

Properties file:

header.description='Tag'

Brief summary:

• Both store the reference (to the text-to-be-translated) and the 'target' language
• PO stores in addition the 'source' language and is hence complete (but holds redundant information)

An incomplete list of aspects:

• .po results in yet another file format and we would love to keep the number of file formats to a minimum
• .po is not in the list of supported file format for SAP Translation Hub, see https://help.sap.com/docs/SAP_TRANSLATION_HUB/ed6ce7a29bdd42169f5f0d7868bce6eb/2c728e75023043cbad70e49cac1d1e10.html?locale=en-US
• .po is well established and comes with a rich tooling ecosystem, see https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
• .properties has no redundant information (as source language is already in the AFF json file)

To finish it off. Suggestions are welcome as we try to understand the relevance and use-cases for translation text for ABAP.

Further reading:
Specification of the #: from https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html

References to the program’s source code, in lines that start with #:, are of the form file_name:line_number or just file_name. If the file_name contains spaces. it is enclosed within Unicode characters U+2068 and U+2069.

[sbcgua]

If my opinion is needed, then as ".po is well established" and "we would love to keep the number of file formats to a minimum", where "properties" is not implemented yet at all, while PO is already productive ... so ... why not to use po ?

Besides, while working on abapGit/abapGit#2539 I faced some unobvious rakes, made some pivots ... e.g. you can follow that very the initial approach was much closer to the properties and also used keys to address the translation place. It had some complications ... e.g. that the keys differ for objects since 740 and before. Which makes text-to-text translation approach a lot more robust, and reliable. Let alone the fact that it is more readable, translatable and supports long-text serialization.

Anyway, comparing a working and theoretical solutions are not super fair. If there were a POC for properties, working in several system versions, covering same object type list as already supported by AG - https://github.com/abapGit/abapGit/blob/main/src/objects/texts/zcl_abapgit_lxe_texts.clas.abap#L201C11-L201C11, including edge cases like missing translations and etc. Then the choise can be more educated. Let alone the fact that the way I implemented translations in AG supports multiple file formats, so no obstacles to parallel development.

[sbcgua]

A word for redundancy ... looks like it is considered a disadvantage ... though it is frequently a part of well-thought and robust IT concepts in many areas, like RAID, CDN, OLAP... Let alone the direct fact that in the case of translation seeing original text improves (if not to say "enable") the readability and translatability of text.

[schneidermic0]

We had meetings with SAP's translation team. Currently, there are no plans by SAP’s translation team to support .po files in SAP’s translation processes. Therefore, they strongly recommend to use .properties instead of .po files.

This means for ABAP file formats, we plan to define .properties files for translations of repository objects.

Just as a disclaimer: SAP's plans might change in the future.

[schneidermic0]

Since it is decided how to proceed, I'll close this issue