Translations

[ryasmi]

Motive
Learning Locker needs strings translated into other languages so that it can be used by people that do not speak English.

Expected behaviour
The user should see text in their chosen language or even better the language that is determined by their current location.

Discussed solutions

1. Add a readme to the lang directory that explains how to add translations inside the lang directory.
2. Use Transifex (we're leaning away from this solution).

Additional information
If you've been tagged here, it's because you've helped Learning Locker a lot in the past. We'd like to hear everyone's thoughts before we move forward.

@fugu13 @gazzastone @garemoko @andytruong @RyanBrainerd @Klaasie @barrysampson

[barrysampson]

Making LL available in languages other than English is an excellent idea, but I would disagree that it is better to select the language based on the user’s current location. We work with a lot of NGOs and other international organisations, and someone’s location is rarely a good indicator of their preferred language. I would much prefer to see language as a user selected profile field.

Have you given any thought yet to support for RTL languages such as Arabic and Hebrew? Support for them goes well beyond translating text strings and means some thought needs to be given to changing the layout.

[gazzastone]

Yes I agree with @barrysampson using the location to base the language on someone's location is generally not a good idea we also have encountered problems using this method in our LMS. We now set a users preferred language in their profile and also allow that to be overridden by use of a language selector on the logon page. RTL languages are not the only languages that pose problems with layouts German language springs to mind with generally longer descriptive text which can cause problems

[ryasmi]

Thanks for your insights @barrysampson and @gazzastone 👍

In terms of detecting the language I think we'll definitely just have a profile option judging by what you're saying.

I'm not too worried about RTL languages and languages like German because we should really be responsive and to me that includes responding to changes of text size and length. The part of the layout that most concerns me with RTL languages would be that we probably align to the left in some cases and I'm not sure how conventional that is for reading RTL.

Do we definitely think that language support is necessary for individual users in Learning Locker as it is after all just an administrative tool?

[ht2]

Problem with true RTL is that the screen should be flipped - things start in the top right, not top left. That's probably a bridge too far for us just now...

[barrysampson]

Do we definitely think that language support is necessary for individual users in Learning Locker as it is after all just an administrative tool?

For me, yes. An LRS captures masses of information, much of it potentially of more interest locally than centrally. Choice of language for local administrators would help with this.

I'm not too worried about RTL languages and languages like German because we should really be responsive and to me that includes responding to changes of text size and length.

Responsive design should certainly help, but don't underestimate how much impact this can have. We recently translated some materials from English to Spanish, French, Portuguese (and Arabic) and every translated version was noticeably longer than the original and required design changes. The problem is less with body text and more with menus, buttons and similar elements.

Problem with true TRL is that the screen should be flipped - things start in the top right, not top left. That's probably a bridge too far for us just now...

Yes, RTL requires a complete change of layout. This is reasonably straight forward to do in a CMS like Drupal or Wordpress that already has a separate theming layer, but it does rely on each theme to provide RTL support.

[ryasmi]

For me, yes. An LRS captures masses of information, much of it potentially of more interest locally than centrally. Choice of language for local administrators would help with this.

Ok thanks for your input.

Responsive design should certainly help, but don't underestimate how much impact this can have. We recently translated some materials from English to Spanish, French, Portuguese (and Arabic) and every translated version was noticeably longer than the original and required design changes. The problem is less with body text and more with menus, buttons and similar elements.

Ok. Yeah I thought that would be where most of the problems would occur.

Yes, RTL requires a complete change of layout. This is reasonably straight forward to do in a CMS like Drupal or Wordpress that already has a separate theming layer, but it does rely on each theme to provide RTL support.

Ok.

Thanks for all this @barrysampson! This is exactly why I put this issue on here to gain these insights 👍

[umutnacak]

@ryansmith94 may I learn the reason why you are leaning away from transifex? Is it because of technical difficulties or something like bad customer relations? I have translated LL into Turkish using the website, and it seemed like a good solution. But when I looked into code of LL, I saw lots of strings that are missing in transifex. I have stated this issue in a group post, but I didn't get any reply. I didn't need to use LL in Turkish so I didn't push anybody to get a reply. Since you have opened an issue here, I would like to resurrect that post.

[ryasmi]

@umutnacak Unfortunately it just doesn't solve our problem. We want to be able to change languages for different users inside one installation of Learning Locker. To achieve that, we ideally want the lang files in a folder inside Learning Locker. Being able to revert to a previous translation would also be useful so it'd be easier for people to just commit translations on here.

[umutnacak]

@ryansmith94 OK, so you need to download the translated file, rename it(for_use_learning-locker_lrsphp_tr_TR.php is the original name for lrs.php), put it in "tr" folder and make a commit in order to make it a part of version control system every time a change happens. So this is a technical difficulty. I don't want to look like a promoter of transifex but I came up with this: https://www.transifex.com/live/ You may want to take a look at that solution.

And what about my group post? Downloaded lrs.php contains Turkish strings only for inline arrays. Like this:

'created'   => 'The LRS was created.',
'active'    => 'Active',
'sidebar'   => array(
        'dash'      => 'Gösterge Paneli',
        'edit'      => 'LRS detaylarını düzenle',

I don't see the 'The LRS was created' string in transifex. But if you are really giving up using transifex, I think you won't bother fixing it :)

[ht2]

Hi @umutnacak - at this stage we will be relying on user contribution through Github to ensure that a language is as up to date as we need. If a contributor finds that a language file is not complete (as with your example for 'The LRS was created'), then they have the ability to submit their own pull request for that language's file, whether that be through their own knowledge of the language or through a translation tool (e.g. Google Translate etc). This also means that users have the ability to submit a pull request for an entirely new language.

Appreciate pointing to the Transifex Live, but we know the direction we are heading regarding translations and it is one where the translations are all available and committed as part of the main repo. We will shortly be building functionality into a user's profile to allow them to change languages based on those available within the repo.

[umutnacak]

@ht2 Fair enough. It's your call. Since your motto is is to become the ‘Moodle’ of the Learning Record Store world, you will eventually create something like AMOS and a GUI for easy contribution, because dealing with pull requests is not easy for everyone.

I already know your reply: "You can create a laravel package similar to AMOS and make a pull request to speed up the process." :) Just kidding.