How to translate special terms, proper names and word formations? What about translation and transcription?

[tokideveloper]

Here we want to solve the following problems when it's about translating both the Qubes website and software:

• How to translate special terms (like "qube")?
• How to translate proper names (like "Dom Zero")?
• What about phonetic transcriptions?
• What about transliterations?
• How to translate word formations like acronyms, portmanteaus etc. (e.g. "VM", "DispVM")?
• Where and when to map between original and translated/-scripted/-literated terms?

[tokideveloper]

It's quite challenging. Instead of giving a quick solution, I'd like to explain the difficulties I see. Maybe we have a linguist who can solve them?

Advantages of not translating special terms

• Easy to lookup them in the official version in case a web page or a piece of software is untranslated.
• Consistency across languages.
• Easy to translate (just do nothing!).
• In case the user has to type in commands then it could be easier for him/her to recognize parts of the commands (like "qvm-…") and thus making it familiar. But note that in the best case the user doesn't need to use the command line!
• Help via email or IRC etc. is currently only available in English. So, the user needs to know the official terms.

Advantages of translating special terms

• Easier to both read and understand and thus reducing the language barrier (which is probably the goal of localization!).

Phonetic Transcriptions

I'm not sure how to translate terms into languages with other alphabets like Russian, Japanese etc.. AFAIK they use their own alphabet(s) and mechanisms (phonetic transcription) to write terms from foreign languages. Thus, it might be awkward for them to keep special terms in latin letters.

Transcription is not a translation. Thus, it might be used beside translation.

Transliterations

Compared to transcriptions, transliterations might be a proper way for languages with other alphabets and better than transcriptions since the whole localization effort we do here is about written stuff (documentation, software etc.), not spoken stuff.

Proper names

E.g. Qubes OS is a proper name. Thus, it should remain untranslated. But should we allow transcription and/or transliteration?

However, qube is a term and not a name (note the case) and may be translated.

Note to translators: The word "dom0" is written in lower case and thus looks like a term but AFAIK it's actually a name (like "Domain Zero") and thus not to be translated.

Glossary

At least the glossary should be the place where the terms and proper names should all be listed together with their origins.

Small solution: Assuming that we know how to translate/transcript terms, I'd prefer to localize the heading of each term to make it easier for translators to lookup terms. E.g. the heading

TemplateVM

may be translated into German with

VorlageVM (TemplateVM)

if we use translated terms. Instead, if we want to use untranslated terms then the resulting heading could be

TemplateVM („VorlageVM“)

with adapted quotation marks.

I think that special terms and proper names should be translated/transcripted/transliterated first which implies that the glossary page should be translated first.

I also think that it's quite useless to translate terms if the software is not translated yet. E.g. if I'd see "VorlageVM" (German for "TemplateVM") in the documentation but can't find that word in the software then I'd feel confused and kidded. So, maybe we should translate the glossary first, then the software and finally the rest of the documentation?

Locations of mappings

In the glossary, there should be a mapping between terms and their translations. But how to do it within normal texts? Some possible solutions in case we only use official terms (the other case might be vice versa):

• Never show any translations of the terms (except in the glossary).
• Give a translation of each term only at its first occurrence on the page.
• Give a translation of each term only at its first occurrence in each section.
• Always give a translation of each term each time it occurs.

The more frequent translations the less readability.

---

Any opinions?
Any ideas?
Any solutions?

[tokideveloper]

It's quite challenging. Instead of giving a quick solution, I'd like to explain the difficulties I see. Maybe we have a linguist who can solve them?

Advantages of not translating special terms

• Easy to lookup them in the official version in case a web page or a piece of software is untranslated.
• Consistency across languages.
• Easy to translate (just do nothing!).
• In case the user has to type in commands then it could be easier for him/her to recognize parts of the commands (like "qvm-…") and thus making it familiar. But note that in the best case the user doesn't need to use the command line!
• Help via email or IRC etc. is currently only available in English. So, the user needs to know the official terms.

Advantages of translating special terms

• Easier to both read and understand and thus reducing the language barrier (which is probably the goal of localization!).

Phonetic Transcriptions

I'm not sure how to translate terms into languages with other alphabets like Russian, Japanese etc.. AFAIK they use their own alphabet(s) and mechanisms (phonetic transcription) to write terms from foreign languages. Thus, it might be awkward for them to keep special terms in latin letters.

Transcription is not a translation. Thus, it might be used beside translation.

Transliterations

Compared to transcriptions, transliterations might be a proper way for languages with other alphabets and better than transcriptions since the whole localization effort we do here is about written stuff (documentation, software etc.), not spoken stuff.

Proper names

E.g. Qubes OS is a proper name. Thus, it should remain untranslated. But should we allow transcription and/or transliteration?

However, qube is a term and not a name (note the case) and may be translated.

Note to translators: The word "dom0" is written in lower case and thus looks like a term but AFAIK it's actually a name (like "Domain Zero") and thus not to be translated.

Glossary

At least the glossary should be the place where the terms and proper names should all be listed together with their origins.

Small solution: Assuming that we know how to translate/transcript terms, I'd prefer to localize the heading of each term to make it easier for translators to lookup terms. E.g. the heading

TemplateVM

may be translated into German with

VorlageVM (TemplateVM)

if we use translated terms. Instead, if we want to use untranslated terms then the resulting heading could be

TemplateVM („VorlageVM“)

with adapted quotation marks.

I think that special terms and proper names should be translated/transcripted/transliterated first which implies that the glossary page should be translated first.

I also think that it's quite useless to translate terms if the software is not translated yet. E.g. if I'd see "VorlageVM" (German for "TemplateVM") in the documentation but can't find that word in the software then I'd feel confused and kidded. So, maybe we should translate the glossary first, then the software and finally the rest of the documentation?

Locations of mappings

In the glossary, there should be a mapping between terms and their translations. But how to do it within normal texts? Some possible solutions in case we only use official terms (the other case might be vice versa):

• Never show any translations of the terms (except in the glossary).
• Give a translation of each term only at its first occurrence on the page.
• Give a translation of each term only at its first occurrence in each section.
• Always give a translation of each term each time it occurs.

The more frequent translations the less readability.

---

Any opinions?
Any ideas?
Any solutions?

[esote]

The Xen project does have a multilingual wiki -- so for terms like "dom zero" I would look at how they do it. For example, the Xen overview page in Spanish.

[esote]

The Xen project does have a multilingual wiki -- so for terms like "dom zero" I would look at how they do it. For example, the Xen overview page in Spanish.

[andrewdavidwong]

Proper names, such as "Tobias" and "Frankfurt," are never translated. However, terms like "dom0," "qube," and "DispVM" are not proper names; they're technical terms. I don't think we should translate technical terms. @esote's link seems to show that the Xen Project doesn't translate them either.

[andrewdavidwong]

Proper names, such as "Tobias" and "Frankfurt," are never translated. However, terms like "dom0," "qube," and "DispVM" are not proper names; they're technical terms. I don't think we should translate technical terms. @esote's link seems to show that the Xen Project doesn't translate them either.

[tokideveloper]

The Xen project does have a multilingual wiki -- so for terms like "dom zero" I would look at how they do it. For example, the Xen overview page in Spanish.

Thank you for the example page! One extracted example:

domUs que viene del inglés Unpriviledge Domain

I.e. they don't touch "domU" and only give the written-out form of it rather than translating it (additionally or not).

[tokideveloper]

The Xen project does have a multilingual wiki -- so for terms like "dom zero" I would look at how they do it. For example, the Xen overview page in Spanish.

Thank you for the example page! One extracted example:

domUs que viene del inglés Unpriviledge Domain

I.e. they don't touch "domU" and only give the written-out form of it rather than translating it (additionally or not).

[tokideveloper]

Proper names, such as "Tobias" and "Frankfurt," are never translated.

Fully agreed.

However, terms like "dom0," "qube," and "DispVM" are not proper names; they're technical terms.

Okay, sounds reasonable.

I don't think we should translate technical terms. @esote's link seems to show that the Xen Project doesn't translate them either.

See my post right above.

My humble experiences with terms (including technical terms) from other languages are:

1. If the term has been invented by e.g. English-writing scientists then the term is English. Now, if e.g. a German scientist writes English or German articles then he/she probably just copies the term in the first runs (this is what you describe). But later, they often find a German term, sometimes more, for the original one. Later, usually one German term is used more often than the other ones. And that term enters the normal German everyday language (and also the scientific language). Thus, this one should be used in the future instead of the original English term. I.e. technical terms are usually translated once they're familiar or heavily used.
2. If an English term is rather a metaphor or something similar (like "shell") then the original English term is used in the German language, too, in order to avoid confusion, I guess.
3. If there is no suitable German term then the English one is used.
4. Often used translated terms are abbreviated with their own acronyms, e.g. "operating system (OS)" became "Betriebssystem (BS)" in German. However, other acronyms like "FAQ" are usually not translated or at least not uniformly.

I think we should keep in mind that the user has to do a job where he/she makes contact with these terms. The more familiar the user is with these terms the less mistakes are made in the job and the more comfortable is the feeling when using that software.

A quick compromise

In the first run: Qubes-concerning technical terms (i.e. all terms in the glossary) shall not be translated. However, other technical terms shall be translated as usual.

In the long run, we should have an open ear for the users and listen what they wish and need.

[tokideveloper]

Proper names, such as "Tobias" and "Frankfurt," are never translated.

Fully agreed.

However, terms like "dom0," "qube," and "DispVM" are not proper names; they're technical terms.

Okay, sounds reasonable.

I don't think we should translate technical terms. @esote's link seems to show that the Xen Project doesn't translate them either.

See my post right above.

My humble experiences with terms (including technical terms) from other languages are:

1. If the term has been invented by e.g. English-writing scientists then the term is English. Now, if e.g. a German scientist writes English or German articles then he/she probably just copies the term in the first runs (this is what you describe). But later, they often find a German term, sometimes more, for the original one. Later, usually one German term is used more often than the other ones. And that term enters the normal German everyday language (and also the scientific language). Thus, this one should be used in the future instead of the original English term. I.e. technical terms are usually translated once they're familiar or heavily used.
2. If an English term is rather a metaphor or something similar (like "shell") then the original English term is used in the German language, too, in order to avoid confusion, I guess.
3. If there is no suitable German term then the English one is used.
4. Often used translated terms are abbreviated with their own acronyms, e.g. "operating system (OS)" became "Betriebssystem (BS)" in German. However, other acronyms like "FAQ" are usually not translated or at least not uniformly.

I think we should keep in mind that the user has to do a job where he/she makes contact with these terms. The more familiar the user is with these terms the less mistakes are made in the job and the more comfortable is the feeling when using that software.

A quick compromise

In the first run: Qubes-concerning technical terms (i.e. all terms in the glossary) shall not be translated. However, other technical terms shall be translated as usual.

In the long run, we should have an open ear for the users and listen what they wish and need.

[andrewdavidwong]

My humble experiences with terms (including technical terms) from other languages are:

1. If the term has been invented by e.g. English-writing scientists then the term is English. Now, if e.g. a German scientist writes English or German articles then he/she probably just copies the term in the first runs (this is what you describe). But later, they often find a German term, sometimes more, for the original one. Later, usually one German term is used more often than the other ones. And that term enters the normal German everyday language (and also the scientific language). Thus, this one should be used in the future instead of the original English term. I.e. technical terms are usually translated once they're familiar or heavily used.
2. If an English term is rather a metaphor or something similar (like "shell") then the original English term is used in the German language, too, in order to avoid confusion, I guess.
3. If there is no suitable German term then the English one is used.
4. Often used translated terms are abbreviated with their own acronyms, e.g. "operating system (OS)" became "Betriebssystem (BS)" in German. However, other acronyms like "FAQ" are usually not translated or at least not uniformly.

I think we should keep in mind that the user has to do a job where he/she makes contact with these terms. The more familiar the user is with these terms the less mistakes are made in the job and the more comfortable is the feeling when using that software.

Very interesting. Thanks for your perspective!

A quick compromise

In the first run: Qubes-concerning technical terms (i.e. all terms in the glossary) shall not be translated. However, other technical terms shall be translated as usual.

In the long run, we should have an open ear for the users and listen what they wish and need.

Agreed.

[andrewdavidwong]

My humble experiences with terms (including technical terms) from other languages are:

1. If the term has been invented by e.g. English-writing scientists then the term is English. Now, if e.g. a German scientist writes English or German articles then he/she probably just copies the term in the first runs (this is what you describe). But later, they often find a German term, sometimes more, for the original one. Later, usually one German term is used more often than the other ones. And that term enters the normal German everyday language (and also the scientific language). Thus, this one should be used in the future instead of the original English term. I.e. technical terms are usually translated once they're familiar or heavily used.
2. If an English term is rather a metaphor or something similar (like "shell") then the original English term is used in the German language, too, in order to avoid confusion, I guess.
3. If there is no suitable German term then the English one is used.
4. Often used translated terms are abbreviated with their own acronyms, e.g. "operating system (OS)" became "Betriebssystem (BS)" in German. However, other acronyms like "FAQ" are usually not translated or at least not uniformly.

I think we should keep in mind that the user has to do a job where he/she makes contact with these terms. The more familiar the user is with these terms the less mistakes are made in the job and the more comfortable is the feeling when using that software.

Very interesting. Thanks for your perspective!

A quick compromise

In the first run: Qubes-concerning technical terms (i.e. all terms in the glossary) shall not be translated. However, other technical terms shall be translated as usual.

In the long run, we should have an open ear for the users and listen what they wish and need.

Agreed.

[tokideveloper]

You're welcome!

I want to add a small thought:

How would Qubes and the doc look like if they were programmed and written from scratch only by people who know only e.g. German (let's assume that all programming stuff they use is also available in German)? Such a Qubes version including doc might look like an ideal translation of the existing Qubes and doc.

[tokideveloper]

You're welcome!

I want to add a small thought:

How would Qubes and the doc look like if they were programmed and written from scratch only by people who know only e.g. German (let's assume that all programming stuff they use is also available in German)? Such a Qubes version including doc might look like an ideal translation of the existing Qubes and doc.