Marc Bernard

Sorry, but I really don't like these "json path property files". A key point of serializing to a file in git is that they are human readable and editable but...

with plain json it would be so much easier to build an integration to the translation hub. isn't that even more a reason to go for json?

The object (array) keys would have to be included just like you showed. Otherwise translators would not have the context. It also allows the json to be sorted.

a question of naming. key fields could go by "id" or begin with "_" (or just "name")

I don't think there needs to be a connection between the serialized JSON of the object and the translation texts. Whatever is reading the translations needs to understand where to...

Correct. Unless it's binary data, the files should be as simple as possible. For humans to edit, or actions/other tools to process. That's why AFF json is much better than...

AG CI has some nice features indeed. If I see it right, the demo checker already includes running the checks and showing results in ALV. You could use something like...

#5458 has been merged. should fix this.

This is not an abapGit issue but an SAP bug: 2859159 - XSLT: Support dependencies on inactive objects https://launchpad.support.sap.com/#/notes/2859159 (See also https://github.com/abapGit/abapGit/issues/5262)

I thought object names (DB keys) are usually all upper case. I wrote a little program to check all keys for tables in OBJSL. There are 122 logical object types...