Q: Referencing translation text in po files

[albertmink]

Assume the interface

interface ZIF_BADI_TADIR_CHANGED_MA
  public .


  methods METHOD_B .
endinterface.

where description of METHOD_B is 'Sun' with associated translation 'Sonne', see SE63

Q1: Does the po file has an entry that looks more or less like?

#: COMPO 00002, maxlen=60
msgid "Sun"
msgstr "Sonne"

Q2: Will be the above entry to converted to

#: COMPO 00003, maxlen=60
msgid "Sun"
msgstr "Sonne"

when adding a method (that alphabetically is before METHOD_B) without translation to the interface

[sbcgua]

Hi Albert, I didn't check but probably yes to both.

[albertmink]

Ok, I see. Just extrapolating what I learned from object type INTF: The file format (referencing the ABAP data in the system) is heavily based around the LXE_OBJ_TEXT_PAIR_READ_XXXX and the table LXE_PCX_S1.

From the example above I derive, that resolving merge conflicts in translations will be rather difficult, since the key is COMPO XY and it is not obvious which METHOD/EVENT/... it is.

[albertmink]

As a heads up:
For the ABAP file format we can assume that there is a JSON file in which almost every translation relevant data is placed (exception are textpool for classes which is a separate file).
An example IF_BADI_TADIR_CHANGED: The JSON (from ABAP file format) is on the left, the properties file on the right.

We believe that referencing array entries via$.descriptions.methods[?(@.name=='AFTER_TADIR_CHANGED')].description instead of alphabetic (?) order $.descriptions.methods[0].description will be more robust and easier to understand for humans. Some documentation we added over the last week is https://github.com/SAP/abap-file-formats/blob/main/docs/properties.md#translation-files-in-abap-file-formats

A way to migrate to properties format, even if there is not yet an ABAP file format, could be the following.
As the translation relevant data might not be in a JSON file, I guess a natural choice is, to stick with the LXE_PCX_S1-key to reference the translation.

[sbcgua]

From the example above I derive, that resolving merge conflicts in translations will be rather difficult, since the key is COMPO XY and it is not obvious which METHOD/EVENT/... it is.

Well, I don't think it will be a big issue, since it is optional comments. But I see how this can be inconvenient. If I were pushing it to the end, I'd probably separate "productive" and "development" modes. The former (and the main one) would not have comments at all. And the "dev" version could be used for a translator and enabled temporarily. Thus it would be both conflict free and convenient and flexible. But it just an idea.

Frankly, and no offends, but ... for me this looks super unreadable and humanunfriedly :))) Sorry. Just IMHO.

[albertmink]

Yeahh, I give you that. I got used to that look. For more nested JSON the identifier gets even longer and the relevant part starts kind of char80 in the line 😵‍💫
Hmm, we tried to make that identifier as meaningful as possible (referencing JSON data, which feels intuitive for AFF).

[albertmink]

Are the productive and development modes like settings in abapGit?

[sbcgua]

Are the productive and development modes like settings in abapGit?

Yeap. As the comments may differ in different systems too. So the question is how and when they are useful. As they do not take part in deserialization, they are ... really comments. And I guess the answer is "mainly during active translation time". While when the package is stable they seem a bit superfluous, and in addition create potential for merge conflicts and deployments. So maybe the process should look like: a) create a branch b) switch on "translation" mode - which will serialize the comments c) do the translation (externally) d) test, blah blah e) switch off comments e) merge the branch

Again, it's just thoughts

[albertmink]

As the comments may differ in different systems too. So the question is how and when they are useful. As they do not take part in deserialization, they are ... really comments.

With comment you mean the #: line in

#: COMPO 00002, maxlen=60
msgid "Sun"
msgstr "Sonne"

right? If so, in which scenario does they differ from system to system?
I assume the goal of a file format is that the same object is serialized independently of the ABAP system. Is this me having Monday morning vibes, or is there a misunderstanding of the 'comment'?

[sbcgua]

Yes, the # lines. The differences between releases (might not be the only ones):

• Translations concept abapGit/abapGit#2539 (comment)
• and the 2nd para of Handling translations SAP/abap-file-formats#106 (comment)