TL;DR; It is hard.

When we have started to build our e-learning platform (Ekademia) on top of Moodle over a decade ago, it was already translated (more or less) to almost a hundred languages. It also had a quite a sophisticated online editor for installed languages - with English being the main one.

But there was one problem, or a mistake judging from the present perspective. We did not have global plans it the first year so most of the visible text and to make it worse - Polish text was baked into the code. This is bad, a very bad practice.

1. It made it hard for us later to find all this text and replace it with translate function. Later we had to list all scripts changed and created by us and analyze every one of them, line by line looking for text backed into a script. And there was a sea of them in over a million lines of code project. If it was an error, that rarely happens, we translated it to English and leave it there. The rest had to be changed into a translate function with corresponding English variable in language packs. Then we’ve used an online language editor from Moodle, to put the original Polish version of the text in the Polish language pack.
2. If you do not plan to go global, changing any text that is baked into a script requires the help of a programmer - one missed backslash before the apostrophe in a critical library and the whole system can stop working.
3. If you bake non-English text and comments into a script or name your functions or database tables using a language other than English, you limit yourself to programmers speaking your language. It’s can be a limiting factor down the road.

Cores of all of our systems were build this way - with text backed into a code. All the scripts of our second biggest system_(e-mail autoresponder impleBOT) had to be rewritten a few years ago to accept other languages. Two other systems (simple CMS impleSITE and viral marketing and one time offers generator impleFUN) will be translated soon.

If you think that translating scripts is hard, wait till you start to work on help documentation and tutorials.

It is tempting and many times the cheapest way to create all your help documentation, tutorials and blog posts in your own language and then translate it into English, and maybe later from English into other languages. It is the cheapest way… in the short-term. As with the code - if you produce your content in your own language, you limit yourself for translators from your own country. You also risk that translation to other languages (made from English translated from your language) will lose original meaning like in the Chinese whispers game.

It is best to create original content in English mostly because it has a relatively simple construction, there is a great number of established tools that help you write in English and most foreign specialists (like programmers) speak or at least understand English.

But say you’ve already created your scripts and documentation in a non-English language. What is the best way to translate it into English and then into other languages?

For non-legal content:

1. Create a new user in Chrome (click your icon in the top right of the browser and choose Manage users) and name it Grammarly.
2. Install Grammarly.com extension for this user and only for this user. Grammarly has access to everything you write on webpages, so it is a security risk to install it on your main browser.
3. Use Grammarly extension to check and correct your writing. I use Calmlywriter.com/online/ to write long-form texts.
4. Replace bare text in scripts with translation function and create basic English translations even using Google translator. The purpose of this step is to exclude programmers as soon as possible from final translation jobs. Their time is too expensive.
5. For finalizing the translation, employ a native English student that lives in your country. Yes - a native student that can read your language will often be the best choice. A professional translator that is fluent in English will always use more artificial language than someone living in Britain or the US. A professional translator will translate the words and a native speaker will translate the meaning and feel. That is why local dubbing for Pixar movies varies a lot from original content. Many if not most of the jokes are changed completely. That way they sound real for local viewers

For legal stuff, there are 2 ways:

1. If you are based in UE, you can just employ a professional translator because the law, for the most part, is the same. Some countries had more strict rules than others (like GDPR states minimal age for personal data decision-making as 13 and Polish law 16), so a check from a local lawyer may be necessary.
   
2. For countries outside your legal system employ a lawyer in the target country for correcting the legal translation that you can prepare in-house or with the help of a professional translator. Sadly this can be the biggest cost in the whole translation project.

When you are done with all this, you should introduce a new policy for your organization. All public content should be created first in English, then translated to your own and other languages. It feels like more work, but there is a great chance that your own countryman will understand English, thus forgive you that some content is in English. The upside is that everything you produce is global ready from day one.

This text was written by me in English. It would be much easier to write in my own language and then give it to translation. But before that, I’ve written almost 2 thousand articles and have not published any one of them in English. It probably can be better, but with every article I write, my vocabulary expands and the number of mistakes lowers. It’s hard to imagine the CEO of a company going global that cannot communicate fluently in English. It’s just another skill one has to master with practice.