search

conedevelopment / i18n

Push your Laravel translations to the front-end and use them easily with JavaScript.
https://pineco.de/using-laravels-localization-js/
MIT License
129 stars 21 forks source link

consider different locales #1

Closed ctf0 closed 6 years ago

ctf0 commented 6 years ago

according to https://pineco.de/using-laravels-localization-js/ we get the default locale and cache it, but what happens when u change the locale ?

the lib can take care of this by switching the translation according to the current app locale which can be acquired by using props on the vue comp init and send it as an option to the class constructor.

then we check if the locale is found in the translations keys locales and either fallback to the default or display empty string, which could be another option sent to the class constructor

iamgergo commented 6 years ago

@ctf0 Thank you for the idea!

Since we need the current language's files, we can solve it only at the back-end side. You are right, we need to change the default config to the current locale.

So that means we need to change this: config('app.locale') to this app()->getLocale()

That means we don't need to pass any locale argument to the translator constructor. If I need the current locale anywhere in my JS, I often do this:

<html lang="{{ app()->getLocale() }}"> and then let lang = document.documentElement.lang

Also, that might would be a good solution, instead of using cache here, we could use view composers. Then we could react immediately to the local changes.

What do you think?

ctf0 commented 6 years ago

i was thinking more of fetching all the locales and save it to the localeStorage like

'auth' : { // file name
  'required': { // key
    en: 'english text', // locale
    fr: 'french text'
  }
}

this way you only prepare the trans once, instead of going through the whole thing each time the user change the locale.

also whether using config('app.locale') or app()->getLocale() its the same as getLocale() basically return config('app.locale')

still, if you prefer to keep the lib as light as possible, we can maybe do all on the backend and display the result as a blade directive like ziggy , this way you dont need to use cache as blade take care of this & it will auto-invalidate when new trans gets added.

iamgergo commented 6 years ago

@ctf0 Hmm, this getLocale() thing is new for me! Thank you!

I think I would keep the JS part like this, this is maintainable for us this way.

But I love the idea about the blade directive! I think I extract the back-end part to a package with the blade directive part.

I link the package here soon!

Thank you for your ideas! :)

iamgergo commented 6 years ago

So we created a package, you can find the docs in the readme! I close this issue, if you think, be brave to open a new issue!

Thank you for the idea!