Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jzb@zonker.net designates
 66.111.4.29 as permitted sender)
Date: Wed, 8 Aug 2012 02:11:33 +0000
From: Joe Brockmeier <jzb@zonker.net>
To: cloudstack-dev@incubator.apache.org
Subject: Re: DOCS: problems with using entities
Message-ID: <20120808021133.GB18096@kodos>
References: 
 <CAKprHVbBAmQ_yJTTP+fuFJQP-oy1pyZjWLoEfGvLz2Sj3YWx8A@mail.gmail.com>
 <6005BE083BF501439A84DC3523BAC82DE44D7E40C8@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <6005BE083BF501439A84DC3523BAC82DE44D7E40C8@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Wed, Aug 08, 2012 at 01:47:25AM +0100, Ewan Mellor wrote:
> Looking at the Publican docs, symlinking a Doc_name.ent to cloudstack.ent 
> (or something like that) seems like the only sensible option open to us.  
> The Publican docs have a long rant about how what we are doing is evil, 
> but I don't see any alternative.

So, I see the point given against using entities for something like a
product / project name, but... it seems to me that if we have a
situation where "Apache CloudStack" or "CloudStack" could be translated
to a language that has several forms, the clued-in translator could be
given leeway to change &PRODUCT; to whatever the proper form of
CloudStack would be. 

For languages where CloudStack would be perfectly acceptable, then
&PRODUCT; could be left as-is.

That is, of course, if we are OK with CloudStack being translated at
all. I'd love to know how other Apache projects handle this particular
situation. 

-- 
Joe Brockmeier
http://dissociatedpress.net/
Twitter: @jzb