[Zope3-dev] Re: Use case not covered for translation of message ids

[Jim Fulton]

Godefroid Chapelle wrote:
> Godefroid Chapelle wrote:
> <snip>
> 
>> I can understand this : while discussing with Stephan on IRC, I did 
>> not know if I was really for the inclusion of this patch.
>>
>> But I really want the current comportment of implicitely translating 
>> messageids coming back from the Python code to stay as it is.
>>
> 
> I think I am using the wrong phrasing here.
> 
> I think both the situation you describe as buggy and the situation you 
> ask for can be spoken as being implicit (though I think using a msgid in 
> the Python code is explicit enough):
> 
> with the following code,
> 
> self.msgid=Message("msgid", domain="another", default="the text to 
> translate")
> 
> <p i18n:domain="zope3" i18n:"translate" tal:content="view/msgid">Some 
> text</p>

                          ^^^^^^^^^^^^^^^^ i18n:translate=""


> the translation of the msgid will *implicitely* happen from the 
> "another" domain.
> 
> Is that implicit ? from the POV of the template designer, yes ! From the 
> POV of the python coder, no !

Yup

> IOW, I mean that the implicit vs explicit wording is the wrong discussion.

Nope.  In the above example, the Python programmer was explicit about
the domain, *not* about translation.

> I think we can go on and on arguing about this as long as we do not 
> agree on the development use cases we mean to cover with msgids.

OK, what use case do you have that requires implicit translation of
message ids?  I can give a use case that requires that they not be implicitly
translated. If message ids are automatically translated, then It becomes much
harder to write applications that manage them.

> I want the message ids to support the translation process : helping both 
> the developer and the designer to cope with their responsibility.

Why?  That is not their responsability, IMO.

> Can you explain what they are for you in the development process ?

They are data.  They specify a message id in a domain, with extra information,
such as default text and interpolated data.  They are *also* strings and
can be used as such.

> Saying that they should behave as string does not convince me : why 
> would I store a domain and a default value on a string if it is not 
> translation oriented ?

Because we use the strings for other purposes. For example, we store titles
and descriptions in schemas.  Schemas and many applications of schemas use
the titles as strings, not as sources of translation.

As I've mentioned before, we could redefine message ids so that they are
not strings.  This would be a huge change that it would take time to understand
all of the implications of.  It *might* be a good change.  I'll admit that I
feel some discomfort in using message ids in schemas.  I question whether the
dubious benefit of implicit translation justifies such a huge change.  What
*is* the benefit of implicit translation?  Does it make anything possible
that isn't possible now?

I'd be open to a proposal to change message ids so that they are no-longer strings.
I don't have time to work on such a proposal myself.  If we decided to move forward
with something like this, we would need to also do a prototype on a branch to assess
the compatability impacts.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org