Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I know this is too late to address for 6.x, but I wanted to start an issue to think about how to handle this in the next version. In http://drupal.org/node/11077 we proposed adding in better timezone handling, and needed to provide a translated list of timezone names. Under the current system, this will create a huge amount of overhead because all those translated names (500+) will be available in the cache on every page, even though they are seldom needed.
So one idea is to add another argument to the t() function to indicate whether or not to cache the translation. The default would be to cache it if it is short, the current process, but have a way to force it not to be cached for situations like this. Then we would not cache timezone names, and instead force database lookups for them. The lookups would then only happen on the pages where those values are actually used.
The only downside is that we might want to cache only a couple of timezone names, local ones that are used often, but I think this system would still work since we could identify a couple names that should not be cached and cache the rest.
Another idea is to create a way to store translated lists as lists instead of as individual items, then do a database lookup to retrieve the whole list in a single pass instead of 500 individual queries.
I'm not familiar enough with the language system to know if this is a practical solution, but thought I'd start some discussion about how to handle this.
Comments
Comment #1
KarenS CreditAttribution: KarenS commented..er should have said we could cache a couple frequently used values and NOT cache the rest.
Also, wanted to note that this would apply to other long lists of infrequently used values like country, county, or city names, for instance. There are a number of places where caching all these values makes no sense and creates a lot of overhead.
Also, shortening the title a bit so it shows up better on the issue tracker :-)
Comment #2
Gábor HojtsyComment #5
jhedstromI think this may have resolved itself in D8 with how translations are stored?
Comment #14
quietone CreditAttribution: quietone at PreviousNext commentedThe last comment here suggests that this issue is resolved and also asked for confirmation. Since there has been no reply in 5 years and much has changed in the 15 years since this issue was open, I am closing this as outdated.
If this is incorrect reopen the issue, by setting the status to 'Active', and add a comment explaining what still needs to be done.\\
Thanks