search

SAP / abap-file-formats

File formats that define and specify the file representation for ABAP development objects
MIT License
58 stars 56 forks source link

Handling translations #106

Closed larshp closed 11 months ago

schneidermic0 commented 3 years ago

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 commented 2 years ago

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

albertmink commented 2 years ago

Pull from remote with changed language does nothing image

image

larshp commented 2 years ago

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 commented 1 year ago

Here just some links to translation relevant topics in abapGit:

schneidermic0 commented 1 year ago

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

schneidermic0 commented 1 year ago

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 commented 1 year ago

👋 Hi there 👋 Over the last months abapGit moved into the direction of .po files (still experimental see https://github.com/abapGit/abapGit/pull/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:

An incomplete list of aspects:

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 commented 1 year ago

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 https://github.com/abapGit/abapGit/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 11 months ago

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