malthe/chameleon — Issue #80: i18n domain from macro overrides i18n domain from fill-slot
Author: jcbrand
Created: 2011-12-19 15:58:16+00:00
State: open

It seems that with the fixes for issue #37, a bug creeped in.

Firstly, from the latest documentation: http://chameleon.repoze.org/docs/latest/i18n.html

> When using translation with METAL macros, the internationalization context is considered part of the specific documents that
> page components are retrieved from rather than part of the combined page.

So, if I understand correctly what you mean...

in context of the chameleon tests, *chameleon/tests/inputs/032-master-template.pt* would be the combined page, where the macro and the slots are defined.

And *chameleon/tests/inputs/070-translation-domain-and-use-macro.pt* would be a document from which components (i.e slot-fillers) are retrieved.

The text says that the i18n context is considered part of the document from which components are sourced from. So the i18n domain of the *metal:fill-slot* node must be "test", and not the i18n domain of *032-master-template.pt*.

This is currently *not* the case however, but there is no test to show that this fails. The reason the tests pass, is because *032-master-template.pt* doesn't define an i18n domain.

If you change *032-master-template.pt* to have an i18n domain, for example:

then the tests break, which they shouldn't because we still expect the slot-filler's domain to be "test".

Looking at the changes made for #37, the following line seems to be introducing the bug (lines 1317 to 1320):

orelse = template(
"SLOT(__stream, econtext.copy(), rcontext, __i18n_domain)",
SLOT=name)

If I remove ```, __i18n_domain```, then the problem disappears and the tests pass.

I'm however not sure if that is the correct fix for the bug since I don't yet understand the context in which __i18n_domain gets defined.