Localization
Localizing applications can be quite tedious, but there are lots of tools available which can help on this procedure. These allow developers to easily localize an application as a secondary step, so that the primary development can be done without caring about localization requirements and tasks.
Using Emby GenericUI, you don't have to deal with HTML and Javascript code. You are developing your plugin as a .NET class library and as such, you are able to employ standard procedures for localizing .NET applications using Resource.resx files and Visual Studio tooling (optionally with the help of VS extensions).
Tools
Many tools and extensions exist. The ones we are using internally are:
Strings in Attributes
Using the Emby Plugin UI framework, you will often end up with a lot of member atttributes in your code which are containing strings that need to be localized. Unfortunately there do not exist any tools to help with the localization of those strings and even ReSharper cannot do that out-of-the box.
This made us create a custom extension for ReSharper for our own needs, which we have published for free:
LocalizationTools.ReSharper
- https://github.com/LocalizationTools/LocalizationTools.ReSharper
- https://plugins.jetbrains.com/plugin/19783-attribute-localization-for-resharper
The following animation shows the way it works:
The only required preparaion is to change the attributes to localizable attributes. You can simply use the ones we ship with our Nuget libaries. Reference here: MediaBrowser.Model.LocalizationAttributes
Essentially, you only need to append the letter L
to all atttributes, so
[Description("My description")]
becomes
[DescriptionL("My description")]
After that, R# will offer you to localize the attribute strings.
Caveat: First, you need to add a Resources.resx file to the project and add at least a single string resource.
Building and Deployment
There's one little problem, though: Localization with .NET works in a way that satellite DLLs are created during compilation for each supported language that are located in subfolders of the compiled DLL. This is incompatible with the way you are publishing plugins to the Emby catalog and again incompatible with the way how Emby is loading the plugins.
Gladly, there's an easy solution to this problem. All you need to do is to add the Nuget package Resource.Embedder
to your plugin project. After doing so, all language resources will be embedded in the compiled plugin DLL.
See also: