The locale system was written so that locale() serves not only for loading existing translations but also for adding a string to be translated if it is not already registered.
The purpose of this was to ensure that code-based strings were available for translation via the UI even if a .pot file did not exist or had not been imported.
However, the fact that anything passed through t() will end up in the locales_source table has led to perennial misuse of t() throughout contrib.
We've tried to address this problem through better documentation, e.g #336115: Additional documentation for t(), but that's unlikely to be tremendously effective.
Another drawback of the current approach is that strings aren't available for translation until they have been displayed somewhere on the site. This means sites admins must return periodically to search for new strings that may have appeared, rather than being able to deal with them all at once.
The alternative would be to make locale() read only. That is, it would only load existing translations. Adding a string for translation would require explicitly calling a method for adding a string.
In practice, sites wanting to translate their interface would need to install the potx module. And we'd need to extend potx to directly extract and add missing translations to locales_source.
Comments
Comment #1
nedjoThis post is for discussion. I'm not at all convinced this is the way we should go, but I think it's worth mulling over. Opinions?
Comment #2
nedjoAdded an issue to potx: #361615: Provide option to record untranslated strings in database.
Comment #3
gábor hojtsyThen it would not be possible to maintain a site with interface translation without potx module, right?
Comment #4
nedjoRight. Which I realize would be a major new dependency.
Comment #5
nedjoI guess another potential approach would be to add potx processing to the packaging scripts. Generate and add .pot files if none exist. Sites would automatically import these files when modules were enabled (or when locale module was enabled), along with language-specific .po files. This would remove the need for sites to install potx.
Comment #6
jose reyero commentedWhat if we add .pot files into all modules as a standard? then we just need to load them and no need potx dependency anymore.
One major advantage of this is that we can use location field as we please, and maybe advance with this other one #334283: Add msgctxt-type context to t()
This way you at least have the module name, plus we can play with string locations and add some meaning there.
Comment #7
catchDoing the processing in the packaging script sounds good. I've seen a lot of support requests where strings weren't showing up in locale because users hadn't visited the right page, would be good to do this more robustly.
Comment #8
gábor hojtsyComment #9
valthebaldlocale() functionality converted to service, I think issue no more relevant