Transcript from the "Internationalization Approaches" Lesson
>> Evan You: And yeah, the final topic that we're gonna talk about is internationalization. Again, internationalization can take very different, can take different styles. There is a plugin called vue-i18n by Kazupon who is a core team member from Japan. And he's been experimenting extensively about internationalization and experimented with three different approaches.
[00:00:32] The first is what we're gonna discuss here, is the most straightforward and obvious solution. But it comes with some performance cost if your app is really huge. And that is, if you want something to be internationalized, you will use this special $t function and give it a slug name for id.
[00:00:53] Which will then go into your locale dictionary and find the correct message and just render it, very straightforward. The other two approaches, the other one is, another one is going with directives. So you do something like v i18n equals welcome message, and then it just goes like this.
>> Evan You: The advantage of using directives is if you don't care about server side rendering, inside directives you can directly manipulate this current element. So essentially the update will be very fast because it doesn't have to go through vue's virtual dom diffing process. So you will achieve slightly better performance, especially when you're dynamically switching between languages.
[00:02:23] As I talked about earlier, templates are static so they're very easy to analyze. So it's possible to, say, inside vue-loader we can add a vue-loader compilation plugin. So there is this hidden feature in vue-loader that allows you to inject custom template compilation modules to allow you to do transforms of vue templates at compile time.
[00:02:46] So Kazupon actually wrote a plugin that analyzed the template at compile time and find references to $t inside the template and compile them. Basically replace them with the correct localized text at compile time, then he builds three different versions of his app and deployed them. So instead of dynamically switching between it at run time, he has three static versions of his app all pre-compiled.
[00:03:22] Now this completely eliminates the run time cost of evaluating, looking up the locales, and you have to ship the locale json dictionary to the client. And all the extra overhead are gone because they're all kind of moved to the compilation phase. So, this is a valid strategy if performance is extremely important and you're okay with the deployment overhead where you have to maintain three branches under three different URLs.
[00:03:53] But if performance gain is huge then it's probably worth it.