Globalization and localization - WilStead/VueCoreFramework GitHub Wiki

The VueCoreFramework provides some built-in globalization support.

Server Side

The server-side C# code uses the default ASP.NET Core globalization model. Make sure to read that documentation for information on how to implement localization for server-side messages. When adding support for additional languages, make sure to add them to the supportedCultures list in the ConfigureServices method in Startup.cs as well as creating the appropriate resource files. Besides being required for server-side localization, the API uses this collection to tell the client which languages should be made available as choices to the user.

Also see the Models.Ilocalizable interface, which allows you to override ToString for your data objects to take an IStringLocalizer object.

Client Side

The client side also has some globalization support built in. Localization on the client side uses an adapted version of LocalePlanet's translate API. The documentation there will be helpful, but there have been two significant changes to VueCoreFramework's TypeScript variation on the library:

• The API's main export is "_t" (not just "_" as in the original library), and does not provide the option to override this with a different choice.
• The translations you supply to the setTranslation function can be complex map objects, with as many levels of hierarchy as you like. When you call the translate function, in addition to the string to be translated you may supply as many additional strings as necessary in order to traverse the hierarchy of your map. For example, suppose your map looks like this:

  {
    "es": {
      "app": {
        "main": {
          "home": {
            "Hello, world!": "¡Hola, mundo!"
          }
        }
    }
  }
  

  In order to translate "Hello, world!" you could call _t("Hello, world!", "app", "main", "home"); The intended purpose of this added feature is to allow you to better organize large translation files, and potentially to allow for the possibility of differing translations for the same source phrase depending on the context.

The ClientApp/components/home component has an example of how localization would be used on the client.

The user management page for signed-in users allows selecting a preferred language from among those the server reports are available. Even though the server and client use independent globalization methods, the client only allows choosing a language supported by the server, to avoid a poor user experience with a selected language receiving only partial support. Note that if only one language is available, the user will not be shown the option to choose a language at all.