Localisation

Help & feedback
1

Restarters are based all around the world. We need to make the interface available in everyone’s own language.
Drop a reply to this topic if you’d like to help translate into your language!

Context

The system is internationalised, in that the infrastructure is in place for adding other languages (although currently based only on string replacements, so if there is any localisation needed in terms of layout, text direction, etc, that would need more work.) However, we need to add a couple of things - allowing user to choose language (both when logged in and when not, for new users); how to manage collecting translations from translators.

Determining which language to display for the user

when logged in

For logged in pages, I would think that the best option is to have a profile setting with which the user can pick their preferred language.

when not logged in

For non-logged in pages (e.g. /about, /user/register), we need to think about:

  • a default language, and
  • how to allow the user to switch between languages

default language

The default language is the language we display the pages in when someone has just navigated to the site.
Some options I can think of: just default to English; or, default to the language based on the location of the user’s IP address; or default to the language based on the user’s browser settings (https://stackoverflow.com/a/674570).

I think using the user’s browser settings is probably the best option. We might make an incorrect assumption of preferred language if just based on geographic location.

Allowing the user to switch language

Basically an interactive language switcher. A simple way is a drop down of different languages. Possibly with a flag displayed as a visual indicator, however trying to match flags to languages is probably a bit of minefield, so probably best to just stick to text.

Managing translations, making it easy for translators

The translation files are currently simple PHP arrays in Laravel. A couple of folks would be happy to go in and edit those in a text editor and push to our git repo, however in general we need a system on top of that to allow translators to add translations in a simple way. There’s a few web based interfaces that exist, some of which are designed to work specifically with Laravel. We need to evaluate those.

Krister mentioned using gettext and pofiles here:

Google seems to provide a service around that for allowing translation of po files in a web interface. I’d prefer something open source though.

2

Hi,

FORUM :
Content in french :
https://talk.restarters.net/c/community-repair/fr

FIXOMETER :
Localization in french :
RESTARTERS-Translated-Texts-FR-20180710.pdf (159,6 Ko)

Saad

3 Likes
3

Brilliant, thanks for these @ssebti !

We’ll be putting those translations in soon, so you can have a test of how they look for you. We’ll also be setting up a web-based system in the next few weeks to know which text needs translations, which ones are missing etc.

1 Like
4

As we add language selection, we’re thinking about how to design the language selector (how you choose which language you would like to see the pages in.)

Here’s a first set of designs - what are your thoughts?

language_selector_001.pdf (1.8 MB)

I think having a language dropdown makes sense for pages where you are a new user and not logged in - e.g. the login page, the about page.

However I’m personally not convinced I need to see a language selector on every page when I am logged in. I would be more likely to set it in my user preferences and likely not change it again, or at least very infrequently. What do others think?

@james @Janet @ugo @ssebti @Karel_De_Schepper

1 Like
5

No remarks here. Functional and clear design. If I can assist for Dutch, let me know :wink:

1 Like
6

That makes sense ! I totally agree.
I have already provided some texts in french, please let me know if you want more.
Thank you,
Saad

7

Makes sense to me - as long as it’s obvious how to change language in the first instance (i.e. someone who speaks no English should be able to find the setting without needing to understand the interface copy).

In the long-term, perhaps there could be a pop-up in the language(s) of the location the user has given asking whether they’d like to switch to that language (or one of those languages) or keep it in English?

8

My current thinking is:

  • In the first instance, the selected language will be based on language negotiation via the browser
  • So, when someone new visits the site, we’ll try to display in the language that is their preferred language as set in their browser.
  • If that language isn’t supported, we’ll default to English
  • At this point the language will be set in a cookie which will be used from this point onwards
  • The visitor will still have the option to change the language via the language switcher, for cases where the default browser language doesn’t apply (maybe it’s a shared computer, or their first preference language isn’t supported, but they would prefer a different supported language than the fallback of English)
  • It language is changed via the switcher, it will be updated in the cookie, so this is used even if visitor navigates away, and returns - so we honour their choice made via the selector from this point onwards, bypassing the browser language negotiation
  • Once fully registered, whatever language is set in the cookie at this point will be set on the users preferences in the database
  • On subsequent logins, the language preference set in the database will be used
  • In a registered user changes preferred language via the switcher while logged in, it will update their preference in the database

I think using the browser language negotiation should cover the case of new visitors to the site being shown the site in their preferred language. Thinking about it, if that language isn’t currently supported, perhaps it would be good to say - ‘Sorry, your preferred language isn’t currently supported. If you would like to help us translate the application please etc etc etc’.

On reflection I’m OK with trying out the language selector being always present in the footer, even when logged in. I think it’s probably superfluous but for visual consistency it will probably make sense to have it there. We can easily hide it again if it turns out to be a nuisance. My concern now is not having it take up so much screen real estate on mobile, I think probably we should have the footer on mobile be hidden/revealable by a smaller component.

1 Like
9

Your translations are now in place @ssebti :tada:

image

:arrow_down:

image
image.png1039×463 125 KB

Thank you again for providing these! There are some missing translations for new things that have been added, or that we may have missed the first time - I can give you access to the translation manager if you would like to help fill these in. Thanks :slight_smile:

2 Likes
10

Excellent ! I’m happy I have contributed :slight_smile:
Saad