On Monday 21 January 2008 11:29, Derick Rethans wrote:
> On Fri, 18 Jan 2008, Gaetano Giunta wrote:
> > I actually like this variant:
> >
> > {tr "There are two options:
> > - Direct delivery through transfer agent (must be available on the
> > server). - Indirect delivery using an SMTP relay server." context "test"}
> >
> > it would be even better if it was supported in the following form also:
> >
> > {tr context "test"
> > "There are two options:
> > - Direct delivery through transfer agent (must be available on the
> > server). - Indirect delivery using an SMTP relay server."
> > }
>
> The latter with having the "context" first, is actually what I prefer as
> well. On top of that, it will possible be a good idea to
> add another construct (say {translation_context "context/name"} that
> sets a default context for the whole template. That's what those
> contexts are meant for anyway, so it'd be silly to have to specify it
> with every string. Of course you can still override it.
The context certainly does not have to be the same for all translations in a
template. But it often is, so the "global context" is good, as long as the
context per translation is also supported.
> There is an issue here though. Because the whole block can be indented,
> there needs to be some form of magic that un-indents the text so that
> whitespace in front of it disappears. I find this a bit magic, and
> actually, I think that in the above example, there should be three
> translatable strings, like:
>
> {translation_context "test"}
> {tr "There are two options:"}
> - {tr "Direct delivery through transfer agent (must be available on the
> server)." - {tr "Indirect delivery using an SMTP relay server."}
>
> Then you can add your breaks as you want. Gunnstein raises the other
> "current best practise" of doing this:
>
> {tr "There are two options:%break- Direct delivery through transfer agent
> (must be available on the server).%breakIndirect delivery using an SMTP
> relay server." vars "break" => "<br/>"
> }
>
> Which works around the whole issue of new lines in strings, and doesn't
> mix markup (<br/>) with text.
Yes, exactly. I really don't like the idea of fancy magic whitespace handling,
and html in translation strings is just wrong.
Those who find that last example hard to read, could split their multiline
string into multiple translations, one per line.
--
Gunnstein Lye
Systems engineer
[EMAIL PROTECTED] | eZ Systems | http://ez.no
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
