You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Backdrop core ships with content translation, which is fine for sites, that really only need content translation.
Additionally there's config translation, which allows to translate certain user provided strings (like site_name, or user mail texts). Config translation utilizes t() / locale() for that. But that concept has its limitations.
There are a lot of user-provided strings, for which there's no standardized translation concept in core yet.
Field labels and help texts
All sorts of notification strings in contrib modules (think of flag, ubercart, eu_cookie_compliance ...)
...?
Using locale for these, too, seems inappropriate, because:
locale always assumes that English is the source language
Using t() for user contributed strings is discouraged because of possible security impacts
Using t() for strings containing markup is far from being ideal
Currently modules that need translation for user contributed strings create their own workarounds or do not have translation for these strings.
It would be cool, if core could provide an additional translation concept for this use case.
Sort of what i18n_strings (submodule of i18n contrib module) does (which also utilizes locale), but smarter, more robust and with better UI.
In the early D8 days it has been discussed to provide something new, based on the i18n concepts, but more complete and without using locale():
Needless to say, that initiative never made much progress.
FTR: i18n for Drupal 7 ships with a submodule utilizing the Variable concept to translate almost everything, but as the Variable module won't ever get ported, and i18n_variable had to be deprecated/removed, there's now a regression in functionality, that's not easy to fix.
i18n_field still provides field (label, helptext) translation, but also using locale() - with all its limitations mentioned above.
This request might be hard to understand for people not needing internationalization / localization, so here's an i18n issue for further reading, beginning with this comment:
Backdrop core ships with content translation, which is fine for sites, that really only need content translation.
Additionally there's config translation, which allows to translate certain user provided strings (like site_name, or user mail texts). Config translation utilizes t() / locale() for that. But that concept has its limitations.
There are a lot of user-provided strings, for which there's no standardized translation concept in core yet.
Using locale for these, too, seems inappropriate, because:
Currently modules that need translation for user contributed strings create their own workarounds or do not have translation for these strings.
It would be cool, if core could provide an additional translation concept for this use case.
Sort of what i18n_strings (submodule of i18n contrib module) does (which also utilizes locale), but smarter, more robust and with better UI.
In the early D8 days it has been discussed to provide something new, based on the i18n concepts, but more complete and without using locale():
https://www.drupal.org/project/i18n/issues/1191662
Needless to say, that initiative never made much progress.
FTR: i18n for Drupal 7 ships with a submodule utilizing the Variable concept to translate almost everything, but as the Variable module won't ever get ported, and i18n_variable had to be deprecated/removed, there's now a regression in functionality, that's not easy to fix.
i18n_field still provides field (label, helptext) translation, but also using locale() - with all its limitations mentioned above.
This request might be hard to understand for people not needing internationalization / localization, so here's an i18n issue for further reading, beginning with this comment:
backdrop-contrib/i18n#39 (comment)
The text was updated successfully, but these errors were encountered: