Translate-plugin: Back-end locale switcher single vs. multi field default behavior

[jimcottrell]

There's been some question in our shop about whether from a UX perspective the back-end locale switcher should default to switching all translatable fields (the current CTRL/CMD click behavior), with the CTRL/CMD click being used to change only one field. I wanted to pose this question to see if there's agreement on that front, or if we'd need to customize if we decide that's the behavior we want to offer our clients.

[LukeTowers]

The switcher is attached to each field so it makes more sense for the default behaviour to be just modifying the field that was clicked. Plus it's not likely to be changed directly in this plugin as that would be a sudden change for existing users; you're probably going to have to go custom on this

[jimcottrell]

I agree that it does make technical sense from the switcher being attached to the field, but where I think there's more of a question is in what a user is trying to accomplish. Does a user generally want to change the language on just one field? Although the CTRL/CMD option is in the README, there's no UI clue that a user can pick up on that there's any other way except for a field-by-field change.

So I guess we'll have to decide if we think we can always make sure any admin is aware of the option, add some kind of UI hint, or customize the behavior in some way.

[petehalverson]

What if we introduce a UI element that allows you to switch them all simultaneously?

That could be done in addition to or in lieu of the existing CTRL/CMD behavior.

[petehalverson]

This is how we've implemented it on an extended version of the plugin:

[LukeTowers]

Looks good @petehalverson

[munxar]

@LukeTowers @petehalverson This solution works great for a single form to sortcut the cmd-click behavior, but for a generic solution I would put the language selector in the main navigation.
Here are my reasons why:

1. It's always visible and reflecting what language we are currently working on
2. It should be persisted over request cycles
3. We could display the translated data in e.g. list views or preview mode
4. We could provide a way to make stuff like 'Preview' work in the selected language
   (because the backend just generates the url for the default language. if the frontend is set to a different language you'll end up with a 404)

what do you thing?

[LukeTowers]

@munxar won't that conflict with the Backend Locale setting?

[munxar]

@LukeTowers I think no. the backend settings affects labels, menu titles etc. the frontend locale will translate the model itself. example of a list displayed in english backend locale:

|       title    |         url     |
| this is a test | /this-is-a-test |
| another test   | /another-test   |

here in german:

|       Titel        |        Adresse    | <- only this is translated to german
| this is a test     | /this-is-a-test   |
| another test       | /another-test     |

only the 'title' and 'url' are translated.
Now with backend locale set to 'en' but frontend to 'fr'

|       title       |        url     | <- from backend translations
| c'est un test     | /cest-un-test  | <- frontend locale
| un autre test     | /un-autre-test | <- frontend locale

In theory it would be a LocalePicker but implemented for backend use. And yes care must be taken that backend locale and frontend locale do not interfere (doable).

[LukeTowers]

I'm mostly concerned about the potential for it to be confusing for the user's (the difference between backend locale changes and frontend locale changes for the data entry). Do you have any thoughts on how to best separate the two in terms of how the user understands / uses them?

[munxar]

imho the way october cms implements it right now, is very confusing (customer feedback). A lot of CMSs i know do it in the way I described it.
think of it like that:

backend locale: languages the backend audience speak
frontend locale: languages the frontend audience speak

the languages can be the same, or they can be totally different.

[LukeTowers]

I agree with that @munxar, but what can we do to make it more clear which is which? My main concern with having a RainLab.Translate locale picker in the menu bar is that users would think it controls the backend locale, not the frontend one. What could we do to make that more clear?

[osmanzeki]

Would it make sense to bundle a new form widget in the RainLab.Translate plugin that is basically an in-page language picker that switches the language of the whole page at once (just like the CMD-Click feature)? Perhaps one that is similar in design to petehalverson's implementation? That way, those who decide that they want this feature can add it to their forms and it's not there if it is not needed?

I think it makes more sense to be able to select any given language from a list in the context of the current form as you don't necessarily want to persist that change across page changes in my experience. Being able to quickly switch between the two-three-four active languages seems to me to be just as useful.

[LukeTowers]

I would lean more towards @osmanzeki's suggestion here, what are your thoughts on that @munxar @petehalverson @jimcottrell?

[osmanzeki]

The form widget could also potentially give the option to persist the language selection as a developer option in the model config YAML. Something perhaps like:

    name: 'Form Locale'
    type: localepicker
    persist: true
    default: 'ca_FR'

That way, everyone gets to control that feature based on their needs. I think for this to work, the widget should show the current active locale in its idle state in a clear manner too.

[munxar]

@LukeTowers @osmanzeki for the context of a 'Form', yes that solution would work and is the most unintrusive. I vote for -> language picker form widget

My problem would be the missing lists, pivots, relation etc. translations, but I think I'll have to write a totally different plugin for that. The current underlying architecture is not working, at least for me.

[osmanzeki]

@munxar

Indeed, I could see how having access to the other languages in other views would be interesting. I think you're right, the architecture becomes an issue here with those needs. You almost need to translate each model as a separate entry in the database. That way you can also achieve true i18n where you can have translated content in only some of the languages.

DecoyCMS (another Laravel-based CMS) is an example of such an implementation:
http://docs.decoy.bukwild.com/localization

[petehalverson]

I'm not sure if I effectively communicated how our solution works. I've published our plugin which extends RainLab.Translate. Give it a try for additional context.

https://github.com/aspendigital/oc-translate-plugin

[petehalverson]

I should mention it applies that switcher to Static Pages (https://github.com/rainlab/pages-plugin)

[vannut]

I really like this concept!
The last screenshot by @munxmar looks cool. To circumvent any possible confusion, you could display both locales next to eachother. On hover display front:nl/back:en;
OnClick display extended dropdown/modal where you could change both locales.

[LukeTowers]

@vannut I'm still not sure about the site wide changer. October doesn't have to be used with a frontend in the first place so I don't think it would make sense to include it structured like that. My vote would be for a dedicated form widget and a way to extend the top menu with that formwidget.