Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Comments
Comment #1
jose reyero commentedI think it makes more sense to show each language native name.
Comment #2
astroman commentedYes, you're quite right. Obvious, really. I am putting a patch together that does this.
Comment #3
astroman commentedSo I changed the title beacuse it's actially native names and alt tags that we want.
I changed the t($string, $args = 0) and locale($string) functions from common.inc and locale.module to accept an additional $lang argument to translate to a language other than $locale, and called this from i18n.inc with the corresponding language.
Comment #4
astroman commentedThat version was buggy - error with cache refreshing. Apologies.
Comment #5
astroman commentedApologies - fixed another error with cache refreshing - needed to track the language of the cached translations stored in the static var $locale_t.
In this implementation, the translation cache is refetched with cache_get if the language has changed since the previous translation. What are the perfomance consequences of doing this? Should we keep the cache for each language once it has been fetched?
-J
Comment #6
jose reyero commentedThis is still "won't fix" for 4.6. It's such a complex patch for this simple feature...
However I'd consider it for inclusion in v4.7 if you get rid of core patches, and provide some i18n replacement for locale's t() function, which could be an interesting addition for i18n api.
Thanks,
Comment #7
jose reyero commentedThis doesn't make sense anymore, the issue has been fixed for latest versions