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

Caching of translation strings isn't possible when embedding them in the html. #4

Closed jeffreydwalter closed 6 years ago

jeffreydwalter commented 6 years ago

This is a cool library! It would be even cooler if instead of loading the translation json into the template, you wrote it out to a php file that sends an application/javascript content-type and injected an include for that file into the template instead. That would put all of the translation strings into an external include instead of embedding them in the page html, which would allow for caching in the browser.

jeffreydwalter commented 6 years ago

I'm new to Laravel, so not 100% sure where you'd do this, but the idea would be to cache the translations in a .php file, l18n.php:

header('Content-type: application/javascript');
session_cache_limiter('private_no_expire');
echo "window.translations = ".json_encode(Cache::get('translations')).";\n";

then include that file in the blade template:

<script type="text/javascript" src="{{ mix('/assets/l18n.php') }}?locale={{ $locale }}"></script>

or whatever.

iamgergo commented 6 years ago

@jeffreydwalter Hey! Thank you for your feedback!

Basically, the blade template is cached until the next change. Also, this is only a blade directive and not a response, which means it serves only a little portion of the whole content.

So I don't think it would be wise to modify the headers and any session config.

Thanks again, I really appreciate your effort!

jeffreydwalter commented 6 years ago

@iamgergo, I get that the template is cached on the server, which means it doesn't have to be recompiled. I think you misunderstood what I'm saying... My point is that when you embed the javascript in html, it can't be cached by the browser, like a .js file is.

iamgergo commented 6 years ago

@jeffreydwalter Yepp, I see, then I misunderstood your point. I still don't know if this has any feelable effect on the performance, but generating a file and pull that in would be faster for sure.

The question is when would you generate the JS file, that contains the translations? When a translation file changes? Or you would just make a command that has to run to refresh the JS?

jeffreydwalter commented 6 years ago

It's a shame that you've closed this issue. This library is suboptimal when you have 1000's of strings, in multiple languages, for a relatively large project. It would suffice to make a command to generate multiple translation js files, one for each language (or you could put everything in a single js file).

iamgergo commented 6 years ago

First of all, how many languages you have does not matter, because the package pulls in only the current one. Then it would not be optimal to separate the JS for all the language files. Also, there is no simple way to automatize this file generation process.

And again, as I said, I don't think that most of the cases there would be any performance issue. Also, I just checked my compiled blade files, and all the translation strings got generated and cached in the PHP file. I really don't think the package should provide more.