I don't know why {{int:}} would corrupt the cache. In fact the cache just has to remember the language for which it generaetd the page (i.e. the value of the "uselang=" query parameter, or by default the language code infered from the "Accept-Language:" header in the HTTP query.

Yes this means that pages may be cached multiple times, but only if they are visited by different users using different preferences for their language. All users will see a coherent page in their own language, the cache of prerendered pages will remain a FIFO and, instead of indexing just on "{{FULLPAGENAME}}", it will index on "{{USERLANGUAGE}}:{{FULLPAGENAME}}".

Note that pages in the cache should also have a short lifetime, if they use any one of the builtin magics that access to the current time:

• if {{CURRENTMONTH}} or {{CURRENTYEAR}} is used, the lifetime should not exceed the current month or year on the server (but anyway, any page in the cache woyuld probably be flushed before, to make room for other cached pages, or jsut because the server was upgraded)
• if {{CURRENTDAY}} is used, the lifetime in cache should not exceed the current day on the server ;
• if {{CURRENTHOUR}} is used, the lifetime in cache should not exceed the current hour on the server ;
• if {{CURRENTMINUTE}} is used, the lifetime in cache should not exceed the current minute on the server ;
• if {{CURRENTSECOND}} is used, the lifetime in cache theoretically should not exceed the current second on the server, but a minimum lifetime of pages in the cache may still be increased, to avoid too much work on frequently accessed pages
• if {{#time:}} is used and takes as default parameters the current time on the server (instead of being specified as constants in additional parameters), the same logic should be applied by detecting which date element was used in the format string (take the shortest element to reduce the lifetime while scanning the format string)
• if some other magic keywords that return server statistics (such as number of pages, number of edits...) are used in a page, these statistics should have a reasonable lifetime.

This means that builtin functions and magic keywords must be able to decrease the default lifetime of pages (but not be able to increase it), according to their semantics, and only after they have evaluated their parameters: their return value is not just a string, but a structure containing the parsed text and the maximum lifetime.

All builtin functions (as well as the template expansor) will see what to do with their parameters : if the parameter is not used (for example because of a #if:, or #switch: that skips some parameters, the builtin functions will not reduce the lifetime of the output string they are creating. In other words, the lifetime for each template parameter, or each builtin function parameter, or the output of any of them are independant.

For example, the #if parser function evaluating:

{{#ifeq:a|b| The current second is: {{CURRENTSECOND}}. |}}

will still return the maximum lifetime, even if one of its parameters has a short lifetime (because its actual value si not used in the output of #if).

On the opposite, with:

{{#ifeq:{{CURRENTSECOND}}|00| I'm up to the minute! |}}

the result will always be dependant of the value of {{CURRENTSECOND}}, because the 1st and 2nd parameter of #ifeq: always needs to be evaluated. This means that the the lifetime of #ifeq: is first initialized as the minimum value of its 2 first parameters being compared (because they are always evaluated), before determining if the conditional 3rd or 4th parameter will be evaluated and returned : the #ifeq: builtin will then reduce (but not increase) the initialized value according to the lifetime computed and returned separately by either the 3rd or 4th parameter.

The same logic should be applied to the lifetime of parameters of conditional builtin functions like: #ifexpr:, #ifeq: #switch:, when computing the lifetime of their returned value : unused parameters should have their lifetime simply ignored, and the returned value will be the minimum lifetime of ONLY the parameters they effectively use in their returned texts.

In all cases, once you have computed the maximum lifetime by taking the minimum of all these values above, check that this lifetime is not below a tuning parameter for the minimum lifetime of validity of ALL pages on the server cache (you may tune it to one minute for example, or less if the server can support it : this may depend on the server or project on which MediaWiki is installed, and on the policy needed for the global page caches used directly in the server, or within front proxy servers). And let the MediaWiki rendering server instruct the page cache about this lifetime of prerendered pages that will be stored there.