Skip to content

Support splitting up messages.js to locale-based .js files #48

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
May 3, 2018

Conversation

carestad
Copy link
Contributor

Seeing as loading the whole messages.js file might be a bit too much, I have added support for splitting up the whole messages.js into .js files for each locale (lang-en.js, lang-es.js etc.).

This way, one could chose to only load the translations for the user's language, by checking App::getLocale().

Also added a @yield (@yield('js-localization.head.exported')) in the view for this that will check for the exported files and include accordingly.

Also updated docs and did some small indent fixes as well.

Copy link
Owner

@andywer andywer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! Good stuff!

Just left a question about the new @section. Doesn't seem to be immediately related to this PRs primary changes.

Otherwise 👍👍

@@ -17,3 +17,24 @@
Lang.setLocale("{{ App::getLocale() }}");
</script>
@stop

@section('js-localization.head.exported')
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that new @section actually a part of the file splitting changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, well, kind of. It allows you to use @yield('js-localization.head.exported'), which in turn will include the <script> tags for the exported files if they exist, and fallback to messages.js or just serving from the API endpoint instead if used incorrectly.

README.md Outdated
This will in turn _also_ generate the following file(s) in your target directory:
* `lang-{locale}.js` contains one language's translation strings, if the `split_export_files` config option is set to true

With static generation you can also make use of `@yield('js-localization.head.exported')` in your blade template. This will automatically include your statically generated .js files for you.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andywer I briefly mention the new @yield here, which is related to the @section part below

@@ -17,3 +17,24 @@
Lang.setLocale("{{ App::getLocale() }}");
</script>
@stop

@section('js-localization.head.exported')
@if (file_exists(config('js-localization.storage_path') . '/js-localization.min.js'))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is quite hard to understand: Why do we check for ${storage_path}/js-localization.min.js and then set the URL to url('/vendor/js-localization/js-localization.min.js') / url('/js-localization/localization.js')?

It's not obvious how ${storage_path}/js-localization.min.js and the URLs relate to each other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right of course. If someone would change the storage_path config, that would not work indeed. Maybe skip the @section altogether? Otherwise one would have to have a function that returns the correlation of storage_path and public_path (if that exists) to be able to figure out where the exported files actually go. And that might be a little bit out of scope for the plugin?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that would probably be the easiest solution now: Removing the section again and changing the Readme to tell the user how to use the locale-specific files.

Could still add a section like this in a follow-up PR.

@andywer
Copy link
Owner

andywer commented Apr 28, 2018

The @section('js-localization.head.exported') is quite hard to understand (see my comment), but if we can make that a bit easier to read it's ready for merge.

Thanks for sharing this!

Copy link
Contributor Author

@carestad carestad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed @section from blade. Updated readme.

@andywer andywer merged commit 0e49474 into andywer:laravel-5 May 3, 2018
stefanschindler added a commit to CampaigningSoftware/laravel-js-localization that referenced this pull request Jan 23, 2025
* Add support for splitting up the messages.js file into language/locale based .js files as well.

* Correct indenting in readme

* Correct typo in README

* Improve README for the static generation part a bit
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants