Adding languages to a website

1

Hi.I want to add a second language to a website I’m building.It works on top of express in the backend and serves ejs files.
So I’m wondering if it is a good idea to create separate subdomains of a page (example: ‘/home’ and ‘/home/en’) and to serve different ejs files, or is it a better idea to pass a parameter and let the ejs file check the language and send the translated content to the browser.Or maybe there are any other options ?
Some things to note here is that I’m not looking into geographical targeting, I want the users to have the option to change the language.
What do you think is a better approach here, that is reliable, fast and SEO approved ?

2

I haven’t done this with ejs specifically, but there are a couple of different approaches. This whole subject is usually called internationalization or localization (i18n or l10n).

  1. Separate web pages for each language.
  2. Set up google translate to automatically translate your page.
  3. Use some coding to select between separate strings based on the language settings of the app/system.

Option 2 is a no go, imho. I’ve seen it done and I’ve seen some disastrous results. Option 1 gives you the most control but is a lot of work and there are a lot of chances for mistakes. i think option 3 is the best - you get a lot of control, but things are broken down into smaller chunks and it’s more DRY.

1 Like
3
4
5

option 3 really depends on how compatible are the two languages and how complex is your website
I have contributed in the past to the internationalization of a website/webapp, it is the most frustrating thing you can do.
Just a video I found once that relates to this:

1 Like
6

Thanky you, seems interesting.I have 2 questions here though:
Does it translate to russian ?
As it is a plugin as written in docs (i18next takes care of these issues for you. We provide you with plugins...), won’t it slow down the website ?

7

Thank you for the reply.It is a simple website.The most complicated is the root page, which mainly fetches data from the database.It’s a portfolio website.I want to have it in 2 languages with different alphabets.

8

You mean option 3? It can translate into your own made up language if you want. You define it. You could have a file called en.js:

const export default {
  greetings: {
    hello: 'Hello',
    goodBye: 'Good bye',
  },
  beverageRequests: {
    coffee: 'I would like some coffee.',
  },
};

and a file ru.js

const export default {
  greetings: {
    hello: 'Привет',
    goodBye: 'Прощай',
  },
  beverageRequests: {
    coffee: 'Я хотел бы немного кофе.'',
  },
};

Yes, by a couple micro seconds. People tend to worry about optimization in all the wrong places. Your site would be slowed down in an imperceptibly small way and most of the time your site is just sitting there waiting anyway.

Then the i18n just knows where to go for the translation.

ieahleen makes a point. I agree that the complexity of the site will make a difference - if it’s just a couple of static pages that never change, then option 1 might be the best.

I disagree that the compatibility of the languages is a factor in choosing (assuming we are talking about the translation languages, not the programming ones). Yes, that can make i18n difficult, but it will be the same difficulty for all three approaches. For option 1, you are still going to have to translate things, for option 2 you’re just going to have more mistranslations you can’t fix, and for option 3, you’re just going to have to do extra work. The app on which I work is huge. Each localization file is over 3000 lines long. And I have to translate obscure trucking slang into Spanish. It’s a pain. But it is a lot easier than having to have two screens for every screen. And option 2 just isn’t an option. For example. trucker slang for a refrigerated truck is “reefer”. Before I got here, no one on the team spoke Spanish so they just typed it into Google Translate and out came “porro”, Mexican slang for a joint. Yeah, option 2 is a lot easier, but can be disastrous. There certainly are times when translating between English and Spanish is a pain - sometimes a button with a 5 letter word becomes an 11 letter word in Spanish, messing up your layout - but that has nothing to do with the i18n solution.

So, unless the app is very small and unchanging - or want to do a lot of duplication work - I think option 1 is a no go. And unless you don’t care about the quality of the translation, option 2 is bad. So, to crib from Churchill, option 3 is the worst option… except when you consider the others.

1 Like
9

My website is small and it looks like I should implement option 1, but I’m not clear on how to translate content that is added to the database.

Let me explain.The heart of the website is the root page which fetches different portfolio projects (photos, title and a description). So here I must write the title and the description in the other language too before POSTing the form to the database (which is MongoDB if that information is useful to you). What do you think of this approach ?

10

I guess I’m confused. If you want them displayed optionally in two different languages, then option three is a good choice. I would want to store it in one language but convert it before it is displayed.

But… if you are talking about unpredictable things from the user that need to be translated, then options 1 or 3 won’t work. For those you would have to manually translate things as they come in. For this situation, I think you would have to rely on some automatic translation service, option 2. But the problem is that you will get some bad translations. This is definitely where the “compatibility of the two languages” comes into play. Translating from Spanish to Portuguese might work pretty well but English to Russian might not work. And forget it if there is a lot of slang or abbreviations.