#1 Today 06:58:39

zen010101
Member
Registered: 2024-06-15
Posts: 179

Proposal: basic i18n for mORMot 2 — wire the existing translation hook

Hi ab,

mORMot 2 currently has no i18n unit, but the framework clearly kept the slots for one when migrating from v1's mORMoti18n.pas:

- TOnStringTranslate / TOnUtf8Translate callback types in mormot.core.unicode (the comments even reference TLanguageFile.Translate from v1);
- the LoadResStringTranslate global hook for resourcestring translation;
- i18nDateText / i18nDateTimeText hooks in mormot.core.datetime (already consumed by the Mustache DateTimeToText helper);
- the Mustache {{"text}} built-in translate tag, and the OnTranslate parameter of every TSynMustache.Render* overload.

None of them is wired anywhere, and the MVC layer cannot even reach the Mustache channel: TMvcViewsMustache.Render calls TSynMustache.Render without passing OnTranslate, and exposes no property for it.

Our concrete need: we are migrating a Java + Tomcat web admin application to mORMot 2 MVC (embedded aarch64 Linux boxes), with a bilingual zh/en UI — about 400 translation keys across ~46 Mustache templates, language selected per request (URL parameter + cookie). So this is driven by a real production application, and we would contribute it in two steps:

PR-A (tiny, self-contained — we will submit it shortly): add an OnTranslate: TOnStringTranslate property to TMvcViewsMustache and pass it down in Render. About a dozen lines plus a test. This just connects the existing {{"text}} channel for MVC apps; language negotiation stays in the application (the callback has no request context, which we believe is the right minimal contract).

PR-B (the actual unit — API to be agreed here first): mormot.core.i18n with roughly:

- TSynLanguage / TSynLanguages: one key->text table per language + a registry;
- loaders: JSON first (TDocVariant-friendly), optionally the v1 .msg format for backward compatibility;
- SetThreadLanguage / ThreadLanguage (threadvar) so web apps can set the language per request;
- one-call wiring: hook LoadResStringTranslate, i18nDateText/i18nDateTimeText, and return a TOnStringTranslate suitable for Mustache / MVC;
- non-goals: VCL/LCL form translation (v1's big part, no UI layer in v2 core), plural rules / ICU MessageFormat (could be an extension point later).

Questions before we write code:

1. Unit placement: a new mormot.core.i18n, or would you rather extend an existing unit? (new-unit additions are your call)
2. Any preference on the language table shape (TSynNameValue vs TDynArrayHashed) and on the loader formats?
3. Is .msg (v1) compatibility worth carrying into v2, or JSON-only?

We would follow the same process as the YAML support (#466): agree on the API here, then submit with full tests (our real 400-key zh/en table as fixture, missing-key fallback, thread isolation, resourcestring hook) on FPC + Delphi.

Offline

#2 Today 08:03:25

flydev
Member
From: France
Registered: 2020-11-27
Posts: 185
Website

Re: Proposal: basic i18n for mORMot 2 — wire the existing translation hook

Just cross linking two threads here for reference:

https://synopse.info/forum/viewtopic.ph … 620#p41620 (mormot.i18n.pas)
https://synopse.info/forum/viewtopic.php?id=7337


I can't wait for i18n support to be added to smile

Offline

#3 Today 09:14:24

zen010101
Member
Registered: 2024-06-15
Posts: 179

Re: Proposal: basic i18n for mORMot 2 — wire the existing translation hook

Thanks flydev — very useful links, I had missed both threads.

That is encouraging: ab already said twice that an official i18n unit is wanted, and your mormot.i18n is a faithful port of the v1 unit — we will definitely use it as a reference for the v1 semantics. The piece we are aiming at here is complementary: a cross-platform core unit (no VCL/Windows dependency, POSIX included), so your VCL scenario and our embedded Linux MVC scenario could share the same table/loader layer.

One more thing I found meanwhile: the framework already has the TLanguage enum with ISO/LCID tables in mormot.core.unicode, so PR-B would naturally key languages on TLanguage instead of introducing a new identity type.

Happy to have you test/review once there is a branch.

Offline

#4 Today 13:56:38

zen010101
Member
Registered: 2024-06-15
Posts: 179

Re: Proposal: basic i18n for mORMot 2 — wire the existing translation hook

Progress update: the first-stage PR is submitted — PR #506, https://github.com/synopse/mORMot2/pull/506 (TMvcViewsMustache.OnTranslate, wiring the built-in {{"text}} channel for MVC apps, with test).

Once it is merged, we will proceed as planned with the second-stage PR — the mormot.core.i18n unit itself, following the sketch and the three open questions from the opening post.

Offline

Board footer

Powered by FluxBB