Łukasz Serwatka a écrit :
Derick Rethans wrote:
On Fri, 18 Jan 2008, Alexandru Stanoi wrote:
Derick Rethans wrote:
On Fri, 18 Jan 2008, Alexandru Stanoi wrote:
I think this syntax would be easier to see for a designer, as
he/she does not need to write text inside the template code, but
inside a block like html.
Perhaps, however, the "vars" part wouldn't be there for most strings, and
perhaps we can do something with the "context" as well, such as setting it
for the whole template. In case we both move them out, we'd end up having
just:
{_ "Hello Derick"}
which is quite a bit easier already than:
{_ "Hello #%nr (%nr2)" context "test" vars nr = $nr + 8, nr2 = 98}
How about other situations where blocks would be nicer?
1. quotes in string need to be escaped:
{_ "Hello Michael \"Air\" Jordan!"}
compared to:
{_}
Hello Michael "Air" Jordan!
{/_}
2. html code in string:
{_ "Hello <ul><li>derick</li><li>alex</li><li>ray</li></ul>"}
compared to:
{_}
Hello
<ul>
<li>derick</li>
<li>alex</li>
<li>ray</li>
</ul>
{/_}
There is an issue with this example (and blocks vs. functions). In order
for the translation component to match the translation with the given
string, it needs to be *exactly* the same - inclusive whitespace.
In both your examples, the original string is not the same. Also, the
whole idea of templates is not to put HTML in code ;-)
But Alex gave good point, here is an example from eZ Publish template:
{"There are two options:<br>- Direct delivery through transfer agent
(must be available on the server).<br>- Indirect delivery using an SMTP
relay server."|i18n("design/standard/setup/init")}
In new syntax that could look like:
{translate context "test"}
There are two options:
- Direct delivery through transfer agent (must be available on the server).
- Indirect delivery using an SMTP relay server.
{/translate}
As "block" it is easier to keep formatting e.g in e-mail templates and
read that code.
Even if we remove those <br> tags from string and we need line break we
will have something like:
{"There are two options:
- Direct delivery through transfer agent (must be available on the server).
- Indirect delivery using an SMTP relay
server."|i18n("design/standard/setup/init")}
With new {tr it will look like:
{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"}
Łukasz
As far as I am concerned, saving a few chars really help both typing
efficiency and readability at the same time. Random thoughts:
- tr not to be used because first time you see it you think about tables
- underscore is good because other translation systems use it =>
familiar. Funky when you see it first, feels natural if you do templates
for a while
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."
}
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. And have vars to
absolutely have a name or would a positional var indexing be sufficient?
Bye
Gaetano
ps: I have no clue as to the rest of the template syntax, sorry.
Whatever looks more inline with the rest of the template syntax is
preferable! ;)
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
