Problems found in Electron/i18n from a standpoint of one translator/proofreader

[ryo-a]

from a standpoint of one translator/proofreader, I found some problem in Electron/i18n on Crowdin.
I hope such problems should be resolved in nodejs/i18n.

No rule for l10n

This problem occured in not only Electron but also other projects.
(Same problem bothered me when I was working on l10n of Android App.)

Ruleless translation usually make chaos in terms of choice of words, grammar, punctuation marks and so on.
Once l10n repo became chaos, it would be painstaking for contributors(translator/proofreader) to set some rules and fix problematic translations.

Styleguide for base(English) documents exists.
I think we need a "translation guide" for every language before starting translation project.

Some terms should not be translated.

Some technical terms(class names, properties, methods...) and sample codes should not be translated but some translators posted machine translated texts.
(FYI:Crowdin provides machine translation suggestion with Microsoft Translation API)

Crowdin can lock specified words to avoid miss translation, so we should designate such words before put files on l10n repo and Crowdin.

Lack of communication between translators

Crowdin has "Discussion" feature but it is not utilized. This is just a simple forum/BBS so not suitable for real-time communication. It may be one of the reasons that many contributors don't use this.

I have an idea; create Slack workspace for channels for each languages (#es,#fr,#ja,#zh-TW...) (and random channels like "#random_ru" might have a positive effect on community of translators.)

At least two active proofreaders are needed per language

there is a proverb "too many cooks spoil the broth" but "only one proofreader" is not sufficient.
so I think at least two proofreaders are needed to maintain translations. It is hard for single proofreader to proofread many new translations.

[FranzDeCopenhague]

My experience as Spanish proofreader in Electron is similar and I totally agree with your comments. Recently @zeke updated the translating contributing section with a set of basic translation rules. This can be a good starting point for our discussions about translation guides and glossaries.

I like the idea of using slack channels to improve the communication between translators/proofreaders.

[amiller-gh]

We had a brief discussion in the Web Redesign meeting about the use of humor in new site copy and what is appropriate for the Node.js brand. Part of that discussion was about how humor translates and how to provide guidance for translators when there isn't a 1:1 translation. Would love to see that get hashed out by this committee as well – either in this issue, or in a new one if its out-of-scope.

[zeke]

This is great feedback, @ryo-a

I think we need a "translation guide" for every language before starting translation project.

I like this idea. We have some intro docs on the electron/i18n README, but there's no guarantee that folks are seeing that page. I think the one page we can be confident that all translators will see is the project landing page on Crowdin, e.g. https://crowdin.com/project/electron -- I've opened electron/i18n#273 as a tracking issue for that.

Some terms should not be translated.

Indeed. In our first pass on Electron, we tried extracting all the translate-able content into a YML format using Electron's structured API docs data, but we quickly found that without the surrounding context, it's difficult for translators to translate arbitrary sentences.

In the end, we decided to upload raw markdown docs to Crowdin, so translators have the full context. The problem with this though is that it exposes all the method names, reserved words, etc, to be accidentally translated.

To help prevent these accidental translations, I've started compiling a Crowdin glossary that uses the globals npm module and Electron's structured API data to assemble a list of glossary terms to give translators more awareness of the terms they're seeing, and help them avoid translating terms that should remain untouched.

[ryo-a]

Thanks, @amiller-gh and @zeke! (and I'm sorry for my late reply)

how humor translates

very difficult but interesting problem for i18n/l10n 🌎🌍🌏

I know one interesting case: Discord's humorous UI texts and documents (also it's humorous translations) have a good reputation in my country. (like this (written in Japanese))
Their documents/experiences might be helpful to us to some extent.

how to provide guidance for translators when there isn't a 1:1 translation

I think there is a simple rule: "keep original meaning but write natural translations in your language." (Of course, some rules are needed even in natural translation )
As far as I read technical documents in Japanese, there are many literal (or unnatural) translations.
Such translations should be avoided in our i18n project as we can.

---

In the end, we decided to upload raw markdown docs to Crowdin, so translators have the full context.

Yes, I think this is the best way as far as we can do! (I know "full context translation" is very important like electron/electronjs.org-old#1064)

In this way, Crowdin glossary plays important role in translation. We should make it be well known by "translation guide" and so on. (e.g. "For translators: Please check glossary carefully before you start translation")

[zeke]

I'm going to close this, as electron/i18n#273 and electron/electronjs.org-old#1064 have been resolved. If there are more things to address, please comment here or open followup issues.