Hi,
Technically not possible to have
{"Hello world ?"} ?
I find one of the really annoying feature of the multilingual features
of ez 3.x is to have the language set by the siteaccess, even if the
content of the node is on a different language.
I'd love to have the ability to change the language of the translation
if I want to (eg to match the language of the active content, or
whatever reason).
{"Hello #%nr (%nr2)" context "test" lang "eng-GB" vars ...}
for instance ? The lang is optional, obviously.
X+
On 22/01/2008, Ole Marius Smestad <[EMAIL PROTECTED]> wrote:
>
> On 18. jan.. 2008, at 15.28, Derick Rethans wrote:
>
> > Hello!
> >
> > I've been prototyping the TemplateTranslationTiein and now need to
> > come
> > up with a syntax for the translation block in the templates.
> >
> > There is a few parts that needs discussing:
> >
> > 1. Which keyword to use
> > 2. How the context specification should look like
> > 3. How optional arguments should look like.
> >
> > In the prototype, it now looks like:
> >
> > {tr "Hello #%nr (%nr2)" context "test" vars array( 'nr' => $nr2 + 8,
> > 'nr2' => 98 )}
> >
> > As a comparison, eZ Publish now is:
> > {"Hello #%nr (%nr2)"|i18n("test", "comment", hash( '%nr', $nr2 + 8,
> > '%nr2', 98 ) )}
> >
> > 1. For the keyword, I can come up with a few options:
> >
> > a. {_ "Hello..."
> > b. {t "Hello..."
> > c. {tr "Hello..."
>
> Of these I think '{tr "Hello..."' is the best, it keeps some
> resemblance to 'translate'. As for '{_' I'm afraid it can quickly
> become a bit cryptic for new users. Although, since this construct is
> something which is going to be used frequently for multilingual sites,
> the string shouldn't be too long either, as such, 'tr' is an ok
> alternative.
>
> > 2. For the context, I can only come up with one example actually:
> >
> > a. context "contextName"
>
> This looks good to me, as long as the template-wide default, mentioned
> elsewhere in this thread, also is in place e.g. '{translation_context
> "test"}'.
>
> However, there is one thing I think would be nice to support in
> addition to translation contexts. Namely, support for comments or
> hints to the translator. Sometimes it might not be trivial for the
> translator to get enough information from context alone to establish a
> good basis for translation. Therefore, I would suggest to also support
> a construct as:
>
> comment "This is the button at the top of the page"
>
> This construct should be optional, and will give the possibility for
> the translators to get extra information in their translation program,
> like QT Linguist.
>
> > 3. And for the arguments the following:
> >
> > a. vars array( 'nr' => $nr2 + 8, 'nr2' => 98 )
> > b. vars 'nr' = $nr + 8, 'nr2' = 98
> > c. vars nr = $nr + 8, nr2 = 98
>
> I would prefer alternative c):
>
> vars nr = $nr + 8, nr2 = 98
>
> > I think I'd prefer (for now), the following syntax:
> >
> > {_ "Hello #%nr (%nr2)" context "test" vars nr = $nr + 8, nr2 = 98}
>
> My take on it:
>
> {tr "Hello #%nr (%nr2)" context "test" comment "Helping text" vars nr
> = $nr + 8, nr2 = 98}
>
> --
> Ole Marius
>
>
>
> --
> Sdk-public mailing list
> [email protected]
> http://lists.ez.no/mailman/listinfo/sdk-public
>
--
Sdk-public mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/sdk-public
