Localization strategy

[daveaglick]

I’ve been thinking about localization and how it could be implemented. Finally have a design I think will work:

• Localized strings are defined as a double dictionary with the first key being the default (usually English) phrase and the second being the locale.
• Localized strings are used in templates either with the context as Context.Localize(“Default phrase”) or a shortcode as <?# Localize “Default phrase" /?>.
• A new Localize module will be used before rendering templates or shortcodes. The module will create output documents for every input document for each locale in the localization dictionary (or only for specific locales if specified in the module constructor). This is in addition to passing-through the original documents (which can be turned off). The write path of these extra documents will by default be /locale/original-relative-path but can be customized. The module will also set a “Locale” metadata key for each new document.
• When the shortcode/context localization method is evaluated, it’ll look for the “Locale” metadata key and then perform the appropriate lookup in the localization dictionary. This has the effect of making the original documents output the default localization string while outputting the lookup if there is one, or the default if not.
• Longer blocks of localizable text can be defined inline (TBD - maybe shortcode content) and will only be rendered when the document contains that “Locale” metadata value.

[spadino]

Great! It seems that can work, indeed. Just some thoughts:

• Double dictionary seems ok for a simple one to one language. However, how would it work for three, four or a dozen language website?
• Having a shortcode to allow for longer block of localizable text works very well. Years ago I had a similar plugin in one of my joomla website, and it was very easy to work with. It remove the needs for duplicate tree (or named .en.md, .fr.md, etcetera files) which is a lovely and elegant solution, as it seems to me.
• There's some misunderstand in regard "localize content" and "translation". They are not exactly the same, and they usually need different approaches. "Localize" is best used as term when dealing with fixed strings - i.e. template strings - which do not are edited very often. "Translation" are more generic and broad than localization, and usually needs the most flexible solution as possible.

[spadino]

An example source file, for a three languages website which default to English, could be like the following:

Lang:
  en:
    Title: Welcome to my english site!
    Description: This is a website. Just that.
  it:
    Title: Benvenuto ali mio sito in italiano!
    Description: Questo é un sito web. Appena questo.
  pt:
    Title: Bemvindo a meu site em portugues!
    Description: (see below)
Published: 3/22/2019
---
<?# Lang "en" ?>
# Welcome!
This is my website. You are reading the english version.
<?#/ Lang ?>

<?# Lang "it" ?>
# Benvenuto!
Questo è il mio sito. Stai leggiendo la version italiana.
<?#/ Lang ?>

<?# Lang "it" ?>
# Benvindo!
Este é o meu site. Está lendo a versão em português
<?#/ Lang ?>

• Missing metadata in the frontmatter will default to the default locale.
• Lang 'code' will provide the output path: i.e. https://mywebsite.org/it/index.html

[eByte23]

I'm just getting to this stuff now. My blog will be in Japanese and English, however the content will be formatted rather different in both so it would be more beneficial for me to do post1.en.md, post1.ja.md

Then probably just have /en/post.1 and /jp/post.1 etc.. However the only other thing will be standard localizations for template strings/resources. Haven't looked at how this done but will be shortly

Updated It looks the strings are hard coded in templates e.g. Archive (https://github.com/Wyamio/Wyam/blame/develop/themes/Blog/CleanBlog/_Index.cshtml#L91) So if IViewLocalizer was used in stead this would allow views to be easily localized. ref (https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-2.2#view-localization)