[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.-1 on using
the same syntax (or at least the same directives) as JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of <%% %%>,
{} or <! @@ @@ !>. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against "live"
data and have the template exist with reasonable "sample" data. [I realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives can
colide. Consider the following:
<div jsselect="items">
<span jscontent="i18n_download">Download: </span> <span jscontent="url">
http://www.some.com/.. <http://www.some.com/>.</span>
</div>
In the above the "i18n_download" span is intended to be a localized string,
and the "url" is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and* a
page composition value within a select directive. The jst replacements that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the "Download" text being
replaced by either "" or null.
It sounds like a C++ solution is being considered, but here are a few humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an obvious
suggestion is just to add another "virtual" JST directive called ("i18n" for
example), that behaves exactly like jscontent, but additionally removes the
element attribute after it's evaluation. So the above example would be
<div jsselect="items">
<span i18n="download">Download: </span> <span jscontent="url">
http://www.some.com/.. <http://www.some.com/>.</span>
</div>
after injecting Spanish strings, it would be
<div jsselect="items">
<span>Descarga: </span> <span jscontent="url">
http://www.some.com/..<http://www.some.com/>
.</span>
</div>
2009/7/8 Erik Arvidsson <[email protected]>
>
> I uploaded a CL of what I initially had in mind.
>
> http://codereview.chromium.org/155245
>
> I realized now that JST is used for non l10n templating so the name
> needs to change. Still, I think this is such a small change with such
> a big win that I want to continue down this path until we have some
> solution for doing the templating on the front end.
>
> 2009/7/8 Jungshik Shin (신정식, 申政湜) <[email protected]>:
> >
> >
> > 2009/7/8 Erik Arvidsson <[email protected]>
> >>
> >> It seems like we want to do the string replacing in the front-end.
> >> Does anyone have any experience with C++ l10n/template libraries that
> >> we might want to use?
> >
> > I don't have, but I just came across a few:
> > http://www.clearsilver.net/ (Apache license, C library, i18n support
> is
> > explicitly mentioned)
> > http://teng.sourceforge.net/ (C++ library, LGPL)
> > http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler
> > than the two above. license unclear)
> > I'll also ask around.
> > Jungshik
> >>
> >>
> >> On Wed, Jul 8, 2009 at 12:00, Aaron Boodman<[email protected]> wrote:
> >> > On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodman<[email protected]>
> wrote:
> >> >> Agree with Erik that it seems like we should share this code between
> >> >> DOMUI and the extensions system.
> >> >
> >> > (Erik Kay)
> >> >
> >>
> >> --
> >> erik
> >>
> >> >>
> >
> >
>
>
>
> --
> erik
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
