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.
> advantages: you can keep opening/closing brackets aligned; having context
> first is easier to read if translated text is a long block. It could even make
> sense for substitution vars (even though all other syntaxes starting from
> sprintf do it the other way round). Otoh if your translated strings are short
> preferences may change.
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.
> And have vars to absolutely have a name or would a positional var
> indexing be sufficient?
Both work with the Translation component:
http://ezcomponents.org/docs/api/2007.2.1/introduction_Translation.html#example-1
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
