Multilingual support - How many of you need it and how?

[estruyf]

One of the features we are currently looking to start working on is the support of multilingual content. Is this something you foresee using or do you already use it? If that is the case, can you share more information on how you would like to see this multilingual support?

[marcocevoli]

Hiya, frankly, I'm not currently using Front Matter, but the lack of a proper multilingual mechanism could be a huge disadvantage if you want to compete against other CMS. More and more sites are bi- or multilingual nowadays, so it's becoming a must. I'm a translator and the owner of a translation/localization company, so my point of view is certainly biased :) . There at least 2 levels of multilingual support you should consider: 1) having all GUI easily localizable, if Front Matter should be used by non-English speakers, 2) having user-generated content easily translatable, in order to have a multilingual site. I wouldn't be much concerned about level 1, because if you're using Front Matter, you're likely a dev and you know English well enough. I would focus on level 2. Professional translators work in specific l10n environment (often called CAT tools and/or TMS, there are major differences, but let's skip this discussion right now). These tools can read pretty much any file format (JSON, XLIFF, XML, resx, etc.) so as long as you can provide a mechanism that keeps the translatable content in a standard file format, you're good to go. This is just a starting point, not meant to be a final answer or suggestion. :)

[estruyf]

Thank you, @marcocevoli - do you know of any suitable format for applying multilingual to Markdown files? Or would you separate these files and link them internally?

I am also in favor to focus first on level 2, level 1 is less of a need, or people need to start asking for it.

[marcocevoli]

Markdown files can be imported and translated in many (not all) of the tools of our trade. It would be probably easier just to put a mechanism in place that only considers files with a language suffix, eg home.it.md for Italian home page, and home.en.md for an English translation. This is how other CMSs are working (Grav CMS for instance). So, basically, a translator (or a certain command in Front Matter) simply duplicates the file with the language code, translates it and puts it into the original folder at the end... Again, bear with me, because I haven't studied Front Matter in depth, so I might say something that goes against the very logic of the program. :)

[bwklein]

@estruyf thank you for starting this issue/discussion, this is a topic that I have been trying to sort out effectively for a few years.

For many sites there are essentially 5 primary sources of information that require translation.

1. Global string pair data for GUI elements: Usually there is some central file(s) that contains a set of strings for translation. In Hugo for example, these translated parameters/strings can be setup in your config file, or in separate files for each language, potentially located in an i18n folder in the project root.

2. Content Translations: Markdown/Asciidoc/RST, etc. files in some content folder require a translated version of that same file.

• Located in the same folder with a suffix in the filename for the language (filename.en.md -> filename.de.md) [example]
• By parallel content directories (/content/en/filename.md -> /content/de/filename.md) [example]
• By some translation key that is the same in all of the files that are linked, regardless of the filename/route of that content file. [example]

3. Menus by frontmatter data or in site configuration.

4. Information in data files that are used to generate information within shorcodes/partials. For example, you might have a JSON file that contains structured data in English. You might need another file in the same directory with the language equivalent of that same data, which would not be ideal as you would need to maintain duplicate data in multiple files.
   If you set this up correctly, and make sure you have 'strings' files in your i18n folder, you could use the i18n function in Hugo to see the source string/phrase in the source data file and render the language target equivalent string where needed in the output. This would eliminate the need for duplicate data files in the data folder.

5. Media assets that might have text in them that would require a paired version of the asset for a particular language target. This might work well with Hugo page bundles or in the media DB there could be some set of filename/path references (in the static folder?) for the image equivalent for each configured language.

I can see tooling in Frontmatter CMS that can help manage cases 1, 3, 4 & 5 fairly easily, as you are ultimately pairing files or strings in one file or location with files/strings in another.

The trickier part would be in content file editing and having a nice split screen editing experience where the content source file is on one side and the target file is on the other and as you are editing a translation in the target file it is matching that 'chunk' or segment of the file with the source and marking that part as translated when the translator is satisfied. This would help identify translation progress over multiple editing sessions. I can also imaging that someone would want to see a live preview of the source and target pages in the dev server version of the site while they are editing to see how the final page layout will look in production.

In addition to that, it would be nice to identify changes to the source file and mark them as changed since the last translation was done, to help translators identify where in their language target file they need to update.

I was thinking that if there was a 'db' file, similar to what you are using now for media assets, but for translations, a lot of the relationships, file changes and 'chunks' could be indexed and used to identify translation state and changes to the source files.

[bwklein]

I realize this is very Hugo specific, but I can easily imagine equivalent features/functionality in other site/app tech.

[mayumih387]

Hi! I don't know if this topic is still active, but as a Frontmatter fan, I would like to share my thoughts. I'm currently running a multilingual dev blog with Gatsby.js (3 languages).

---

Multilingual content support

Content:

I agree with what @bwklein mentioned;

it would be nice to identify changes to the source file and mark them as changed since the last translation was done, to help translators identify where in their language target file they need to update.

However, we don't know if the line numbers are always the same in every language...

One other idea is to have a DeepL (or anything else translation API) connection like Strapi.

Media:

For media, it would be nice if we could add multilingual metadata like title and caption. But sometimes some media items are specified for only one language (for example, screenshots of English page and French page), it would be nicer if we can choose if the media is for multilanguage or not.

Taxonomy:

It would be nice if data files could have locale columns, as they can be used for categories, tags or global menus.

Dashboard:

It would be nice to have a language filter. Personally, I don't really use the dashboard, but as the project grows, I imagine a language filter would be helpful.

But you may need to consider which type of locale the user identifies for each content: directory name (/en/first-post.md), filename (/first-post/en.md), filename suffix (/first-post.en.md), or YAML metadata (lang: "en").

Linking content between languages:

Since I use the filename (/first-post/en.md) for language identification in my blog, I don't really see the need for content linking. But in other naming ways, or if the filenames are different for each locale within the same content, it would be better to have some linking method.

---

GUI multi-language support

If the localization is added to Frontmatter, it would be great. Especially the documentation or the YouTube tutorials, it should be hard to understand everything if you are not used to English. It's a shame that non-English speakers can't get to know Frontmatter, or even get there but leave immediately when they find it's only in English. I think Frontmatter should become more popular.
(I would be happy to help you translate the GUI or documentation into Japanese. Talk to me whenever you need :)

[estruyf]

Thank you, @mayumih387 it is great to gather all those ideas and come up with the best of all.

About the GUI multi-language support, it would be great to have someone like you pick up this task, it would definitely help others!

[estruyf]

First steps towards a multilingual UI have been started: #598

[mayumih387]

Great! Can we send pull requests for translation files ? (Me, Japanese)

[estruyf]

Of course! That would be great.

[estruyf]

Multilingual support in Front Matter CMS is finally here: https://beta.frontmatter.codes/docs/content-creation/multilingual

Feel free to give it a try in the latest beta.

[zivbk1]

Thank you!!!

[estruyf]

It took a long time, but I didn't want to make the wrong decision to create a system that was too opinionated. I believe we now have something open enough to support various use-cases.