You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For efficient and consistent translations, it is handy to have a glossary. A glossary can describe the meaning of terms in an app to a translator not immersed in the app's world. Also, a glossary can list whether terms should be translated and what recommended translations are.
Use of a glossary ensures consistent translation, even when translators for the same target language/region succeed each other.
Currently there seems to be no glossary on Bluesky.
I have created a basic one. I would like to add it somewhere, so other translators can use it as a starting point and maybe add to it. Over time it can grow: developers can add definitions when they introduce a new concept, translators can find what something means and what common translations in other languages are.
Question 1: When there is consensus, where should it be placed? Suggestion is to have one glossary for the whole project with the definitions in English and translations where available (I can create derive existing standards from existing translations).
Question 2: What file format should be used? Suggestion is to use TBX v3 (see https://www.tbxinfo.net/tbx-downloads/) since it is XML and makes parallel changes possible since git diff can merge these. TBX can be converted in other formats used by Computer-Assisted Translation tools such as XLIFF or text. Alternative might be the use of Localazy when there is some kind of foundation; they offer a USD 74 monthly solution for CAT of Bsky (our company is leaving it since our quantity of translation rseources is too large / complex).
Describe Alternatives
Alternative 1: leave it as is.
Advantages: no upfront work, common for most developers
Disadvantages: increasing work per resource translation to keep consistency, harder to add new languages, harder to add many languages by professional translation agency since they must create the glossary themselves.
Alternative 2: add glossary
Advantages: improved scaleability, reduces total labor when there are many translations
Disadvantages: requires handling of this issue
The text was updated successfully, but these errors were encountered:
Describe the Feature
For efficient and consistent translations, it is handy to have a glossary. A glossary can describe the meaning of terms in an app to a translator not immersed in the app's world. Also, a glossary can list whether terms should be translated and what recommended translations are.
Use of a glossary ensures consistent translation, even when translators for the same target language/region succeed each other.
For more information see for instance:
Currently there seems to be no glossary on Bluesky.
I have created a basic one. I would like to add it somewhere, so other translators can use it as a starting point and maybe add to it. Over time it can grow: developers can add definitions when they introduce a new concept, translators can find what something means and what common translations in other languages are.
Question 1: When there is consensus, where should it be placed? Suggestion is to have one glossary for the whole project with the definitions in English and translations where available (I can create derive existing standards from existing translations).
Question 2: What file format should be used? Suggestion is to use TBX v3 (see https://www.tbxinfo.net/tbx-downloads/) since it is XML and makes parallel changes possible since git diff can merge these. TBX can be converted in other formats used by Computer-Assisted Translation tools such as XLIFF or text. Alternative might be the use of Localazy when there is some kind of foundation; they offer a USD 74 monthly solution for CAT of Bsky (our company is leaving it since our quantity of translation rseources is too large / complex).
Describe Alternatives
Alternative 1: leave it as is.
Advantages: no upfront work, common for most developers
Disadvantages: increasing work per resource translation to keep consistency, harder to add new languages, harder to add many languages by professional translation agency since they must create the glossary themselves.
Alternative 2: add glossary
Advantages: improved scaleability, reduces total labor when there are many translations
Disadvantages: requires handling of this issue
The text was updated successfully, but these errors were encountered: