I’ve considered the advantages and disadvantages of using Language files versus Template files for i18n multilingual support management methods, so I’ll introduce them.

Multilingual support methods

When using Language files

Advantages

• When adding more languages for multilingual support, you just need to add language files for those languages
• Low maintenance cost

Disadvantages

• Managing sentences containing HTML tags in language files becomes awkward
• When different languages display different features, branching like if (lang === 'en') appears in template files
• Sometimes language file modules can't handle cases where the overall meaning is the same in English and Japanese, but the context doesn't match at the sentence level

Reference information for languages, frameworks, libraries, etc.

• Rails国際化 (I18n) API | Rails ガイド
• mashpie/i18n-node: Lightweight simple translation module for node.js / express.js with dynamic json storage.
• 多言語化 5.3 Laravel
• Philipp15b/php-i18n: Simple i18n class for PHP with caching and and ini, json and yaml support

When using Template files

Advantages

• Can provide optimal presentation for each language, not just simple translation. Can be customized extensively
• Removes branching like if (lang === 'en') from template files

Disadvantages

• File count becomes enormous: "number of languages × number of template files"
• If template files have complex logic, it becomes duplicate management, so code maintainability becomes poor unless properly shared
• High maintenance cost

Multilingual support policy summary

If you assume no complex customization for multilingual support (= just translation), I recommend managing with Language files. If different languages display different features, I recommend the approach of separating template files by language.

That’s all from the Gemba where I don’t want to suffer with multilingual support.