Re: I18N text domains for zopeproducts

"Fred L. Drake, Jr." <[email protected]> Thu, 14 Aug 2003 17:58:25 -0400
Newsgroups	gmane.comp.web.zope.internationalization
Message-ID	<[email protected]>
Stephan Richter writes:
 > Note that this domain was added there, so it can reuse Zope 3's
 > translations, which is very sensible in my opinion.

Yes, I understand this goal, and agree that it's very reasonable.

 > No, not all. But the Bug Tracker (where this check in is coming from) will 
 > always depend heavily on zope.app. And that will never change.

It's not clear to me that depending heavily on zope.app should be a
reason to share the text domain with zope.app.  I can't think of a
Zope 3 product that doesn't depend on zope.app to provide
infrastructure, whether it access that by importing a lot from
zope.app or picking things up mostly from context.

 > Mmh, I disagree. This really encourages a lot of duplication in
 > translations. On the other hand, one could argue that there should
 > be tools that detect equal translations and fill them in
 > automatically before someone even starts to translate. Note that
 > this is the type of functionality our Web-based translation manager
 > should handle (if you do not know what I am talking about, ask
 > Barry).

There's certainly a lot of precedent for this, and there are at least
some tools and relevant specifications regarding translation memory.

Jim Fulton writes:
 > That's right except in those cases where a product is intentionally
 > reusing a message id from the zope domain, which is what's happening
 > here.  We might want to give some more thought about how this should
 > happen.  For example, it should be an error for an add on product to
 > use a message id that isn't defined by the domain.

Re-using a message id and using someone else's text domain "whole
hog", with new message ids and everything, are two different things.


I'll make an observation and a micro-proto-proposal here:

The set of message ids defined for a text domain is similar to the set
of functions, classes, and methods defined in a software package.
Some are internal, and some are for external consumption.  What
message ids are available for external use should be explicitly named
and documented; anything else is internal.  An "exposed" message id
should always be assign an explicit message id that's the public
interface.  3rd-party software that wants to use the message id must
name it with both domain and message id, but should not create new
message ids in the domain; a separate domain should be created for
private messages ids.

So I'd expect bugtracker templates to have markup like this:

<html i18n:domain="bugtracker">
   ...
   <span i18n:domain="zope" i18n:translate="public-id-from-zope">
     something
   </span>
</html>


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation