[2.x] Inertia: Revert default Vue i18n implementation

[claudiodekker]

This PR reverts the internationalization changes that were introduced to 2.x earlier this year, for multiple reasons:

• Lots of people don't use translations in their apps at all, as they are not targeting an international audience
• The implementation has a lot of surface area, and it's configuration makes a 'clean install' look overly complex.
• Assuming you don't use translations, this implementation would then unnecessarily add a lot of extra bytes to your build.
• Third-party translation services might not support/use vue i18n, forcing you to re-do the integration anyway.
• Implementing Vue i18n yourself does not take too much time.

[reinink]

While I totally appreciate the work @bonzai put into this, I agree with this PR. The i18n implementation just feels like "too much" for Jetstream. It makes the views busy and less readable for everyone who doesn't need translation support (which I suspect is a lot of users).

[bonzai]

@taylorotwell There is a translation support in the Livewire stack - shouldn't it also be removed?

[Enrica-r]

It's too bad that translation won't be integrated. I want to develop an application with german labels. Nobody is developping an applicaton with german parts in the source code (I hope so). So I expect that I18N should be important for all non English speaking areas. With the argument above translations could be removed everywhere in Laravel, Livewire stack etc. I18N increases the complexity always.

I have intended to write code to convert all "lang//*.php or *.json" into an exported JS object (oneper language) or json file plus a helper JS function which imports the translation messages of the current language if not yet loaded. "My dream" was to have Laravel's translation mechanism on Vue side automatically without writing own code.

@bonzai : Probably you could document your work somewhere or build a separate package which could be imported in app.js. I read a lot web sites concerning translations in vue but no description was so clear for me as your implementation. Thank you for your work.

[GENL]

You must use this package https://github.com/GENL/matice to bring the power of laravel translations in InertiaJs, and generaly in the JavaScript code with a total flexibility and no client side framework dependency.

[drjdr]

@claudiodekker @reinink @bonzai @taylorotwell
I regret to see this disappear :'(

Translation support in Laravel is a major benefit of the framework, having it done in a standard and uniform way in Inertia.js Jetstream just feels right, with easy customisation in app.js (e.g. use auth.user.locale preference).
A lot of countries (or especially websites outside of the the tech-scene) do not use english as the main language. Also some larger websites require to have the information in the languages of the country for compliance reasons. Not the majority I agree, but a lot.

It is relatively easy to use Jetstream Inertia.js in your app and not be bothered about $t() in the jetstream part, just like with __() in Laravel form error messages, whereas having to add translations in the app requires to edit all the jetstream pages... making breaking changes to all of the components. Having this done in Jetstream Inertia (especially in combination with the error messages for forms coming from Laravel Translations) is a good use case for the majority of users that require translations in a basic app.

i18n is a widely supported implementation on the vue side, with many extensions, documentation etc and seems a good choice. If only looked at https://github.com/Laravel-Lang/lang it seems that there is wide support with 76 languages for the default laravel lang. If translations are added in a uniform way, we can see this as well for this jetstream inertia.js implementation.

Given that the UI aspect of jetstream: adding translations to the main project will enforce other plugins in the future (e.g. @joelbutcher 's socialite integration) to work in this consistent way. Which would not be the case if every plugin comes with no translations or a custom way... having the user to hack in $t()s or similar in each plugin.

[claudiodekker]

@drjdr I understand your disappointment, but there's really nothing keeping you from re-implementing this in your apps.

I really don't want to turn this into an endless discussion between personal preferences, but I strongly believe that the goal of Jetstream isn't to be good at creating a specific kind of application, but rather for it to give it's users a great starting point to create any kind of application. I don't necessarily disagree that translations should be a part of Jetstream, but rather that it shouldn't be at the cost of the downsides that this specific implementation brings, as I listed in the PR's description.

[bonzai]

I understand your disappointment, but there's really nothing keeping you from re-implementing this in your apps

@claudiodekker Umm... that's why if you don't need it, "there's really nothing keeping you from" removing it.

As you said:

Jetstream isn't to be good at creating a specific kind of application, but rather for it to give it's users a great starting point to create any kind of application.

Do you think it's a great starting point if there is no i18n support?

Also, is there any reason why you didn't remove it from the Livewire version? Now again, there are differences between those two stacks, and I think that's not the point in Jetstream.

[drjdr]

@claudiodekker
Certainly not wanting to make this an endless discussion, and I respect your choice and hard work. Thanks a lot!

I'm just worried that having no uniform translation support in inertia will result in a very fragmented landscape of implementations, or... plugins with no translation support at all.
i18n with $t() is a specific, opinionated implementation, but so is the Laravel with __().
Basically this is the dead of uniform multilingual support in this jetstream stack, making it inferior to the livewire start you can get.

[simonj]

We never get an answer why it's only for livewire :( @claudiodekker