| Child pages (Children Display) |
|---|
...
Eine veraltete Kopie, die hier nicht aktualisiert wird:
| Panel |
|---|
- Translations are moved from Lokalise to the
/translations/ directories of GitHub repositories by a script that Peter Murray runs every few days. They show up as a pull request on each stripes-* and ui-* repository, are run through the CI tests, and automatically merged. CI tests don't always pass and may require manual restart.
- This is a one-way process. Any manual change to locale files on GitHub will be overwritten and are lost when new locale files from Lokalise come in.
- https://folio-testing.aws.indexdata.com/ is the first reference environment where new or changed translations appear because it uses the master branch. Other reference environments take longer because they only use released front-end module versions, see Reference Environments for details.
- Any FOLIO release like Honeysuckle, Iris, etc. ships with the translations that come with each front-end module. Each front-end module has a different release date (Honeysuckle example). This is the time when translations are taken from module's GitHub translations directory and is different for each front-end module. A new front-end module release is needed to get more recent translation included into a FOLIO release.
- However, the sysOp of a FOLIO installation may manually update the translations of their installation by exchanging the files in the
/translations/ directory from where the static files are shipped. One option is to take the latest translations from https://folio-testing.aws.indexdata.com/ , use the browser developer tools to find out the current number folio-testing uses, for example https://folio-testing.dev.folio.org/translations/de-1605513539114.json, take the .json file, and rename the .json filename to match the number of the own installation. If the own installation has front-end modules that not exist on folio-testing then merge the folio-testing into the own translation file: jq -s '.[0] * .[1]' de-1601343197440.json de-1605513539114.json > de-1601343197440.json.new
|
...
| Notwendige Festlegungen | - Substantivierung oder Tätigkeitsbasierung
- Substantive zusammensetzen oder Bindestriche setzen
- Einzelentscheidung; grundsätzlich zusammen, aber wenn es der besseren Lesbarkeit dient, mit Bindestrich
- Punkte am Ende des Satzes oder ohne Punkt
- aktive oder passive Formulierungen
- Eindeutschen, Bspl.: Discovery oder Kataloganzeige
- Genderneutralität wahren, Details siehe Gendern
- Direkte Anrede (Option 1 favorisiert von Jana, Martina S, Kirstin und Peter)vermeiden
|
| Bereits erfolgte Festlegungen | - Englisch - Deutsch Konsistenzen
- leichtere Pflege
- (wenn doch Abweichung, auf Liste setzen und in der Gruppe besprechen)
- Auch wenn ein Kommando kein kompletter Satz ist, dennoch Großschreibung des ersten Begriffes (gemäß § 53 Deutsche Rechtschreibung)
- bei häufi verwendeten, allgemeinen Begriffen Kontext nicht ergänzen;
- Bspl.: "Beschreibung" nicht "
Beschreibung der Vereinbarung" oder "Vereinbarungsbeschreibung" - "Name" nicht "
Vereinbarungsname"
- wenn möglich Kurzformen und nicht Sätze verwenden
- Begriffe sollten im Deutschen Sinn ergeben
- Bspl.: "line" wird bei "PO line" mit "Posten übersetzt = Bestellposten
- für Agreement lines ergibt diese Übersetzung keine Sinn
- bisherige Vorschläge: Vereinbarungszeile, -eintrag, -inhalt => ENTSCHEIDUNG: Vereinbarungskomponente
- Buttons werden wie im Englischen mittels Verben beschrieben
- Checkboxen werden mittels Adjektiven beschrieben
- Bspl.: "Suppress from Discovery" = "Nachweis unterdrückt"
- wichtige Begriffe am Anfang eines Strings (Subjekt vs. Objekt)
- englische Fehler an die verantwortlichen Entwicklungsteams melden
|
...