Specify language when translating templates?

[yongtw123]

My goal is to compile templates in multiple languages for reuse in my program. According to documentation, I can just specify a "language" string $lang like so

$latte->addExtension(new Latte\Essential\TranslatorExtension($translator, $lang));

However it's unclear how $lang is used within the compilation pipeline. Surely I shouldn't add the same extension to a Latte Engine instance multiple times since the last added one overrides the previous.

// NOT GOOD
$latte->addExtension(new Latte\Essential\TranslatorExtension($translator1, 'en'));
$latte->addExtension(new Latte\Essential\TranslatorExtension($translator2, 'ja'));
$latte->renderToString('template.latte', $data); // this will only use $translator2

I can create multiple instances of Latte Engine to achieve my goal, but then the $lang parameter feels redundant. However if this is indeed recommended usage, then what's the purpose of $lang? To help Latte differentiate the compiled templates?

// Intended & recommended usage??
$latte1->addExtension(new Latte\Essential\TranslatorExtension($translator1, 'en'));
$latte2->addExtension(new Latte\Essential\TranslatorExtension($translator2, 'ja'));
$latte1->renderToString('template.latte', $data);
$latte2->renderToString('template.latte', $data);

Suggestions are welcome!

[MartinMystikJonas]

What do you want to achieve? Precompile all templates to warm up cache?

[MartinMystikJonas]

Without $lang parameter there is only one cached compiled version of template that translates strings every time it is rendered. If you use $lang parameter then cached compiled template contains translated strings for given language (translated at compile time) so there is no need to translate them every time during rendering. And yes there would be cached compiled template for every language with language specific strings already translated.

[yongtw123]

Thanks, that cleared things up. So the $lang parameter is used pretty much as an id to differentiate among multiple versions (i.e. languages) of the same template by creating multiple compiled ones with each containing its corresponding translations.

As a sidenote I would have preferred if $lang can be passed into $translator so that I need only one translator function instead of many. ;P

[MartinMystikJonas]

Problem is that information about current language inside translator is not known to latte compiler. If you set language to translator then latte compiler do not know what language is used. If you want to pre-compile different versions of template you have to let latte compiler know what language is currently selected by adding latte translator extension with lang parameter specified.

I am not sure what you mean by many translator functions. You will alway have just one translator (and one latte translator extension) with currently selected language.

[yongtw123]

The function signature of $translator seems to only accept a key and expect a translated string in return, thus to my understanding 1 language corresponds to 1 translator function, and 1 translator function corresponds to 1 instance of translator extension. As result, if there are N languages, I must define N translator functions.

What I meant was that it'd have been convenient if I can, say, just define 1 translator function which accepts an extra $lang parameter for looking up a dictionary. But of course I can work around this.

[MartinMystikJonas]

No you should have just one Translator and one TranslatorExtension. Selected language is part of internal state of Translator. Different Translator implementations use different methods to set/detect current language. Single Translator can translate to all language versions depending on selected language.

[yongtw123]

I must be missing something important here. Pardon for the prolonged discussion.

As per the Latte documentation:

$translator = function (string $original): string {
	// here we create $translated from $original
	return $translated;
};
$latte->addExtension(new Latte\Essential\TranslatorExtension($translator, $lang));

Unless stated otherwise, it seems the only way to set language is by creating a new instance of TranslatorExtension. ($lang's value is used at construction of TranslatorExtension, and the property is declared private. No public method of TranslatorExtension allows changing the value either.) Moreover, according to TranslatorExtension's implementation and var-dumping func_get_args() inside $translator, $lang is not passed into $translator. So, in order for $translator to detect the value of $lang, some external mechanism must be implemented. Apparently $translator in this sense does not have an "internal" state storing selected language?

[MartinMystikJonas]

I think you using it other way around. Do you implement your own Translator or do you use any existing library?

Usual mechanism is similar to this:

1. Translator service is created
2. app determines current language
3. current language of Translator service is set
4. Before rendering tempalte you create latte engine and add TranslatorExtension that references translate method of Translator service and asks Translator service about current language

You are creating your own translate function but usual mechanism is to reference some service of your app that handles translations and also holds current language.

$translator = new TransatorService();

$lang = detectLanguage();
$translator->setLanguage($lang);
....
$latte->addExtension(new Latte\Essential\TranslatorExtension([$translator, 'translate'], $translator->getLanguage());

Maybe if you give my more context of your intended use case I can give you better hint.

But basically minimalistic implementation based on your example would be something like:

$lang = detectLanguage();

$translator = function (string $original) use ($lang): string {
	if ($lang == "en") {
          return translateToEnglish($original);
        } else {
          return $original;
        }
};
$latte->addExtension(new Latte\Essential\TranslatorExtension($translator, $lang));

[dg]

I tried to improve it in the documentation, hopefully it's clearer now.

[yongtw123]

@MartinMystikJonas I think I see the difference now. My use case is static site generation, e.g. thousands of pages sharing the same template but with different data and in different languages, and due to that data retrieval is more costly for me, I retrieve data once, subset them, then render each subset in N languages in one go. For efficiency, I reuse Latte and TranslatorExtension instances rather than creating them on-demand like in a web app.

@dg Thanks for the update. Didn't know translations can be done on runtime!

[MartinMystikJonas]

@dg What about option to pass $lang in form of callback that returns current language? It could simplify use with language aware translators becquse it would remove need to replace TranslatorExtension on language change. I think I can draft a PR if you like the idea.