On Thu, Oct 8, 2009 at 12:55 PM, Steven Roussey <[email protected]> wrote:
>
> Arg! Google Groups somehow messed up my long and reasoned post. So now
> I'm retyping a short version. Grrr!
>
>> I think the simplest thing would then be to have 2 template expansions again.
>>
>> file english.strings:
>> greeting: "Hello {name}"
>>
>> file spanish.strings:
>> greeting: "{name} Hola"
>>
>> file page.template-for-template: # this file has all your HTML structure
>> <p>
>> {greeting|translate}
>> </p>
>
> At this point, it is simplified my having 'translate' be an included
> type formatter. If it could grab a language option from the context,
> it could use that to include greeting_en or greeting_es, for example.
> So in the complex case of in-place substitutions, we just use other
> json-template files. In my experience, these type of cases represent
> only 5% of all translations, so it seems a reasonable course.
OK good, but it is nice to keep multiple strings in a single file,
rather than having a file per fragment.
>> I don't see the point of {[ ]} in your examples. {.translate}{.end}
>> looks better.
>
> Assuming the complex case is taken care of by a include type formatter
> named translate above, the simple case, which represents 95% of the
> cases (the simple word/phrase) is the thing to think about.
>
> I think if people see {.translate}Hello{.end}, they will certainly try
> {.translate}Hello {name}{.end} instead of using the method above.
> Also, people that write templates tend to add translation hints only
> when it is easy. So I'd say that [Hello] would be a real benefit.
> Though having four meta characters would be a pain in other ways.
{[Hello]} is ugly -- strings aren't supposed to appear inside
metacharacters. {.section}strings appear like this{.end}
Maybe if there are 2 use cases for {.block} we could have it.
{.block greeting} # This identifies a template fragment
Hello {name}
{.end}
{.block|translate} # This defers expansion of {name} until after the
'translate' formatter is applied
Hello {name}
{.end}
I'll have to think about it. I guess the common thing is that you're
identifying a template fragment which is not immediately expanded.
The thing I don't like about {.block} for includes is that it only
have one level. I mean can you do
{.block foo}
{.block bar}
nested
{.end}
{.end}
?
> So what I think would be best would be {[Hello]} for translation of
> simple strings.
>
> Here are the changes I propose:
>
> 1. Formatters get a way to look at options (through the context
> object?) so that they can know the language.
Formatters can already look at the context object (in the spec and in
Python, needs to be ported to all languages).
> 2. To activate the simple translation system, users must supply two
> additional options: the name of the formatter that does the
> translation (I'd call it getttext), and the inside meta chars to use.
>
> Assuming {} as the meta chars and -- as the translate meta chars, you
> would use {-Hello-} to translate Hello.
>
>> Are you really translating a web app now?
>
> Yes. CRDL and all that stuff. Oh, what fun.
What's CRDL?
>> Actually I do have marginal experience with some translation on Google
>> Code
>
> You work at Google? Is json-template uses there for any projects?
A little bit but not much. Google already uses about 15 template
languages, probably 6 of which are written in house, and several which
have been open sourced... so there is not much benefit to pushing
that. Over time I think people will pick it up naturally, especially
with the importance of JavaScript and JSON, e.g. to Chrome.
Andy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JSON
Template" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/json-template?hl=en
-~----------~----~----~----~------~----~------~--~---
