Comments (12)
๐ 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.
from abap-file-formats.
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.
from abap-file-formats.
Let me try to summarise the current (not final) approach.
.abap
files do not contain translation relevant content- Files containing structured data (
.json
) indicate theiroriginalLanguage
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. - Text symbols are not part of the
.json
and 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)
from abap-file-formats.
I just add a link to a POC which tries to handle abapGit translations:
https://github.com/sbcgua/abapgit-translation-poc
from abap-file-formats.
Pull from remote with changed language does nothing
from abap-file-formats.
SCP1 contains translations, https://github.com/SAP/abap-file-formats/blob/main/file-formats/scp1/type/zif_aff_scp1_v1.intf.abap#L133-L149
from abap-file-formats.
Here just some links to translation relevant topics in abapGit:
from abap-file-formats.
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 #510
- Using
.properties
files. See #511
This approach is kind of similar to abapGit/abapGit#2539.
Difference is one file per object and language instead of all translations in one file per repository.
from abap-file-formats.
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.
from abap-file-formats.
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.
from abap-file-formats.
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.
from abap-file-formats.
Since it is decided how to proceed, I'll close this issue
from abap-file-formats.
Related Issues (20)
- Allow validation of JSON examples for `formatVersion != 1` HOT 6
- Validation of JSON data for multiple formatVersions
- Enum values for `abapLanguageVersion` are not documented HOT 1
- Could you please define format for TTYP (Tabletypes)? HOT 3
- GitHub Action "Validate JSON schema / validate (pull_request)" seems to be broken HOT 3
- please avoid some special characters in file names HOT 5
- DOMA feedback HOT 4
- [CHKV] Wrong parameter length in CHKV HOT 2
- [COTA] Add example HOT 1
- One of Mutliple Fields is Required HOT 1
- Could you please define format for DTEL (Data Element)? HOT 4
- [ILMB] Add example
- DMON + NONT + RONT doesnt have title + description in generated schema HOT 3
- use `.acds` extension for DDL? HOT 8
- ISO 639-1 is not sufficient for language fields HOT 11
- Translation and the need of a format version
- Q: enums with default being $required
- what are "ABAP repository objects"? HOT 5
- Improve markdown link check HOT 2
- Generate JSON Schema fails for version != 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from abap-file-formats.