Had another thought: scoping.
The macros import without issues, but they are limited to overall_header.html and will not work in any child templates (navbar_header, etc). The best way around this seems to be to declare them as global variables.This allows the test string to be used in all child templates of overall_header.html, while maintaining ease of translation. It looks a bit daft, because you could just declare the globals without the other stuff, but then you wouldn't have the ease of translation that you get from the separate language files. Using the same name for the global and the macro does not seem to cause any issues, and should make things easier on the brain (fewer names to think up and keep track of).
For strings that are required in templates other than overall_header or its children it will be necessary to do the import tricks again, as well as the setting of variables if you want them in child templates. That suggests that the sanest way of organising things would be to name the language files after the parent template which calls the strings in them (overall_header.twig, posting_editor.twig, etc) to minimise the amount of stuff that needs to be imported.
And obviously if you just want to use your custom strings in the actual parent template there would be no need to also declare them as globals. Just importing the macros will work in that situation.It's not a perfect system, but it's perfectly workable. It's unlikely anyone will want to use large numbers of custom strings.
The macros import without issues, but they are limited to overall_header.html and will not work in any child templates (navbar_header, etc). The best way around this seems to be to declare them as global variables.
Code:
{% set lang_file = "language/" ~ S_USER_LANG ~ "/overall_header.twig" %}{% if source(lang_file, ignore_missing=true) is not empty %}{% import lang_file as styleStrings %}{% else %}{% import "language/en-gb/overall_header.twig" as styleStrings %}{% endif %}{% set testString = styleStrings.testString %}For strings that are required in templates other than overall_header or its children it will be necessary to do the import tricks again, as well as the setting of variables if you want them in child templates. That suggests that the sanest way of organising things would be to name the language files after the parent template which calls the strings in them (overall_header.twig, posting_editor.twig, etc) to minimise the amount of stuff that needs to be imported.
And obviously if you just want to use your custom strings in the actual parent template there would be no need to also declare them as globals. Just importing the macros will work in that situation.
Code:
{% set lang_file = "language/" ~ S_USER_LANG ~ "/posting_editor.twig" %}{% if source(lang_file, ignore_missing=true) is not empty %}{% import lang_file as styleStrings %}{% else %}{% import "language/en-gb/posting_editor.twig" as styleStrings %}{% endif %}Statistics: Posted by Gumboots — Fri Apr 11, 2025 10:21 pm