hi list -

there is a great GNU library for dealing with localisation, that has a
php function gettext()
http://www.php.net/manual/en/function.gettext.php

many high-end PHP projects use this (wordpress, drupal).

I was wondering if there is a way to use this with smarty?

basically gettext is a php function, so if this is used in the middle
of a smarty template, it will make templates really ugly. I think!
Unless there is a clean way to inline php funcs inside smarty...

also, since a php funciton is being called in the middle of a
template, i imagine this stops smarty from being able to pre-compie/
cache the template itself?

So, any suggested approaches?

Can a modifier function work directly on a string? eg if i created a
localize() modifier that called gettext, then:

had a template like this:

{ "message list" | localize }

rather than puttig the english "message list" in a separate tag to be
passed to smarty:

{$messageListTag|localize}

this would require all the tags to be read in ahead of time, and
another level of indirection + probably reading lots of irrelevant
tags per page.

thanks for any as always!

/dc
--
_______________________________________________
David "DC" Collier

dc@pikkle.com
skype: callto://d3ntaku
http://www.pikkle.com
+81 (0)80 6521 9559

http://charajam.com$B!!!Z!z%-%c%i"v%8%c%`!z![(B
$B?M5$%-%c%i$H(BJ-POP$B:G?7%R%C%H6J$r<+J,$GAH$_9g$o$;$F(B
$BBT<u(BFlash$B$dCe(BFlash$B$r:n$C$A$c$*$&!* (B
_______________________________________________

On 30 May 2006, at 13:11, D_C wrote:

> basically gettext is a php function, so if this is used in the middle
> of a smarty template, it will make templates really ugly. I think!
> Unless there is a clean way to inline php funcs inside smarty...

You really don't want to do that...

> also, since a php funciton is being called in the middle of a
> template, i imagine this stops smarty from being able to pre-compie/
> cache the template itself?
>
> So, any suggested approaches?

Yup. Wrap it up in a Smarty plugin. Many smarty plugins are no more
than this, so try looking at some. You might need a pair of plugins -
an initializer (e.g. to select and load an appropriate language file)
and a modifier to display a text item. The popup plugins work this way.

> Can a modifier function work directly on a string? eg if i created a
> localize() modifier that called gettext, then:
>
> had a template like this:
>
> { "message list" | localize }

Yes, you can use this syntax. Try for example {"hello world"|
escape:"url"} and it will render to 'hello%20world'.

There are several Smarty translation mechanisms around (including
some that use gettext) - try looking at the wiki: http://
smarty.incutio.com/

Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk

You really don't want to use it, since the performance gains are negligible
from a custon made library getting the stuff from a DB -I've done and made
benchmarks and the results are similar with an edge going to custon made
libraries when you're using high ammounts of translated terms- .

For legibility reasons I implemented my system as block plugin:
{translate}text{/translate} and added some localization functions to deal
with numeric format etc..

On 5/30/06, Marcus Bointon <marcus@synchromedia.co.uk> wrote:
>
> On 30 May 2006, at 13:11, D_C wrote:
>
> > basically gettext is a php function, so if this is used in the middle
> > of a smarty template, it will make templates really ugly. I think!
> > Unless there is a clean way to inline php funcs inside smarty...
>
> You really don't want to do that...
>
> > also, since a php funciton is being called in the middle of a
> > template, i imagine this stops smarty from being able to pre-compie/
> > cache the template itself?
> >
> > So, any suggested approaches?
>
> Yup. Wrap it up in a Smarty plugin. Many smarty plugins are no more
> than this, so try looking at some. You might need a pair of plugins -
> an initializer (e.g. to select and load an appropriate language file)
> and a modifier to display a text item. The popup plugins work this way.
>
> > Can a modifier function work directly on a string? eg if i created a
> > localize() modifier that called gettext, then:
> >
> > had a template like this:
> >
> > { "message list" | localize }
>
> Yes, you can use this syntax. Try for example {"hello world"|
> escape:"url"} and it will render to 'hello%20world'.
>
> There are several Smarty translation mechanisms around (including
> some that use gettext) - try looking at the wiki: http://
> smarty.incutio.com/
>
> Marcus
> --
> Marcus Bointon
> Synchromedia Limited: Putting you in the picture
> marcus@synchromedia.co.uk | http://www.synchromedia.co.uk
>
> --
> Smarty General Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Vicente Werner y Sánchez

On 30 May 2006, at 14:22, Vicente Werner wrote:

> You really don't want to use it, since the performance gains are
> negligible from a custon made library getting the stuff from a DB -
> I've done and made benchmarks and the results are similar with an
> edge going to custon made libraries when you're using high ammounts
> of translated terms- .

Personally I think gettext is a clunky way of working anyway! I'm
using a DB-based one at present - it's nice to have a separate web
interface for translators to use independent of web apps.

> For legibility reasons I implemented my system as block plugin:
> {translate}text{/translate} and added some localization functions
> to deal with numeric format etc..

I've done it as both block and function - I find functions are tidier
for small things like field titles. I've yet to come up with a nice
way of handling embedded variables like gettext does, especially with
numbered params. Any ideas on that?

Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk

On 5/30/06, Marcus Bointon <marcus@synchromedia.co.uk> wrote:
>
> On 30 May 2006, at 14:22, Vicente Werner wrote:
>
> Personally I think gettext is a clunky way of working anyway! I'm
> using a DB-based one at present - it's nice to have a separate web
> interface for translators to use independent of web apps.


There're other issues I considered, as the need to reboot apache when you
change the .po files so they're loaded and the hit just for initilizing the
system.

I've done it as both block and function - I find functions are tidier
> for small things like field titles. I've yet to come up with a nice
> way of handling embedded variables like gettext does, especially with
> numbered params. Any ideas on that?



What I did was a modification of the block function so it could get a list
of vars that were substitued on the string.


Marcus
> --
> Marcus Bointon
> Synchromedia Limited: Putting you in the picture
> marcus@synchromedia.co.uk | http://www.synchromedia.co.uk
>
> --
> Smarty General Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Vicente Werner y Sánchez

thanks for all the comments. quite interesting what related issues a
question brings up :0

> There're other issues I considered, as the need to reboot apache when you
> change the .po files so they're loaded and the hit just for initilizing the
> system.

is this really the case? Wordpress and Drupal both use gettext and PO
files, and yet I cant imagine people in shared hosting restarting
apache...

in terms of performance, does the syntax suggested above:
{translate}some string{/translate}

mean that smarty cannot pre-compile the templates? (I'm not exactly
clear how all that works, so please bear with me! I think that the
template itself is converted to a php file, then each time a page is
displayed that uses it, things go a little quicker. but if there is an
area where possibly non-static content might be passing through a
function, this would mean the conversion to php also would happen
every time?)

also, for performance and clean templates, what about just using config files?

{#someString#}

of course, some kind of management GUI would be needed for building
the config files, but this isnt too big a deal.

tx,

/dc

On 5/30/06, D_C <lister@pikkle.com> wrote:
>
> is this really the case? Wordpress and Drupal both use gettext and PO
> files, and yet I cant imagine people in shared hosting restarting
> apache...


From the php manual:
winXP, PHP 4.3.5 as Apache1.3.29 module

Two hints for Windows users.

I found setting locale is neither sufficient nor nessecery. To get it work I
needed to set either LC_ALL or LANG enviroment variable to my locale. Anyway
this value must be proper for setlocale so it is good to test with it. In my
case it was bgr_BGR for bulgarian according to
http://www.unicode.org/onlinedat/countries.html

gettext checks for files once and keeps them in cashe. Especially it means
that if it doesn't find your files it won't search again, so restart Apache
after any directory changes!!

I know it's a windows specific issue, but I've seen similar issues on linux
machines.

mean that smarty cannot pre-compile the templates?


Not at all, my system just uses such marks to store the string for future
translation , which is done as a last step, after everything is rendered.

also, for performance and clean templates, what about just using config
> files?
>
> {#someString#}


They're clumsy and unmanageable when the ammount of translation items and
languages goes beyond a certain limit. A db is much more manageable.

of course, some kind of management GUI would be needed for building
> the config files, but this isnt too big a deal.
>

You can have a q&d web front end in less than an hour, adapted to your
needs.

--
Vicente Werner y Sánchez

On 30 May 2006, at 15:50, D_C wrote:

> mean that smarty cannot pre-compile the templates? (I'm not exactly
> clear how all that works, so please bear with me! I think that the
> template itself is converted to a php file, then each time a page is
> displayed that uses it, things go a little quicker. but if there is an
> area where possibly non-static content might be passing through a
> function, this would mean the conversion to php also would happen
> every time?)

You are confusing compiled templates and cached output. Smarty does a
one-time conversion of your template syntax into straight PHP and
keeps it in ./templates_c. This 'compiled' template is just regular
PHP that gets run like any other script, and as such can have
whatever dynamic content you like. The next step is to cache output
(in ./cache) from the compiled script, which smarty does if you turn
caching on ($smarty->caching = 1). This output is of course
completely static, but it has almost zero overhead to deliver. Smarty
can mix cached and uncached elements within a page (by including sub-
templates that are cached within ones that are not, see $smarty-
>caching = 2 in the docs too), so just because one part of your page
is dynamic doesn't mean you have to lose out on caching altogether.

That clearer?

Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk

hi -

> > also, for performance and clean templates, what about just using config
> files?
> > {#someString#}
>
> They're clumsy and unmanageable when the ammount of translation items and
> languages goes beyond a certain limit. A db is much more manageable.

well, there are a few different issues:
authoring (maintaining)
template cleanliness
runtime performance

whether or not we build a web front end + db to manage the string
editing (we have) is a different matter from how smarty accesses
things.

I wonder if you have an idea for runtime performance which is quicker:

{"someKey"|localize}

which would look up the key (db read) and then return the right lang value.

vs.

{#someKey#}

which would replace the above based on a config file (means reading in
the config as a text file eg "strings.jp" ).

i guess (2) is faster. then we just need a web front end to manage
(read/write) config files.

for many people collaborating on basis of text files would also be easier.

as written below. took us more than an hour to build it tho!

/dc

>
> > of course, some kind of management GUI would be needed for building
> > the config files, but this isnt too big a deal.
> >
>
> You can have a q&d web front end in less than an hour, adapted to your
> needs.
>
> --
> Vicente Werner y Sánchez
>


--
_______________________________________________
David "DC" Collier

dc@pikkle.com
skype: callto://d3ntaku
http://www.pikkle.com
+81 (0)80 6521 9559

http://charajam.com　ã€�★ã‚ャラ♪ジャãƒâ˜…】
人気ã‚ャラã�¨J-POP最新ヒット曲を自分ã�§çµ„ã�¿å�ˆã‚�ã�›ã� ¦
待�Flashや�Flashを作��ゃ���
_______________________________________________

hi -

> >caching = 2 in the docs too), so just because one part of your page
> is dynamic doesn't mean you have to lose out on caching altogether.
>
> That clearer?

yes, thats awesome, thanks.
so basically all the language dependent stuff (eg menu button names)
can be cached.
And changeable stuff (eg userName) can get processed each page.

hwoever, i think this means using {insert} and sepearate files, so
things will get a bit broken up. there isnt a way to do something like

{#menuName}
{noCache}
{$userName}
{/noCache}

to allow all the cache/nocache content to be in one file?

thanks a lot!

/dc


--
_______________________________________________
David "DC" Collier

dc@pikkle.com
skype: callto://d3ntaku
http://www.pikkle.com
+81 (0)80 6521 9559

http://charajam.com$B!!!Z!z%-%c%i"v%8%c%`!z![(B
$B?M5$%-%c%i$H(BJ-POP$B:G?7%R%C%H6J$r<+J,$GAH$_9g$o$;$F(B
$BBT<u(BFlash$B$dCe(BFlash$B$r:n$C$A$c$*$&!* (B
_______________________________________________

http://smarty.php.net/manual/en/caching.cacheable.php

Look at
*Example 14-11. Preventing a whole passage of a template from being cached*


D_C wrote:
> hi -
>
>> >caching = 2 in the docs too), so just because one part of your page
>> is dynamic doesn't mean you have to lose out on caching altogether.
>>
>> That clearer?
>
> yes, thats awesome, thanks.
> so basically all the language dependent stuff (eg menu button names)
> can be cached.
> And changeable stuff (eg userName) can get processed each page.
>
> hwoever, i think this means using {insert} and sepearate files, so
> things will get a bit broken up. there isnt a way to do something like
>
> {#menuName}
> {noCache}
> {$userName}
> {/noCache}
>
> to allow all the cache/nocache content to be in one file?
>
> thanks a lot!
>
> /dc
>
>

On 5/30/06, D_C <lister@pikkle.com> wrote:
>
> whether or not we build a web front end + db to manage the string
> editing (we have) is a different matter from how smarty accesses
> things.


On a live environment, the manageability of it it's also a factor to take
into account: it's not the same a system where you're actually adding new
terms/translations each day than one that remains the same.

I wonder if you have an idea for runtime performance which is quicker:
>
> {"someKey"|localize}
>
> which would look up the key (db read) and then return the right lang
> value.


That's the WRONG way to do things: The main advantage of a DB over a text
file is that the time needed to return multiple rows is smaller than to get
the same replie on a text based file.

On my system, when you're ready to translate a page there's a query much
like this one:

SELECT strSTRING,strTranslation FROM tblTerms WHERE coLanguage = 'EN' and
strSTRING IN ('list','of','strings','to','collect');



> {#someKey#}
>
> which would replace the above based on a config file (means reading in
> the config as a text file eg "strings.jp" ).

While it might be true -something that I doubt, specially on virtualized
environments where the DB is on a different host- for a single instance,
when you deal with 10's,100's or more translatable items it becomes a fuckin
big problem, also if you speed up things by pre-loading all the
translations, you hit the memory consumption, something you don't with the
DB based approach.


> for many people collaborating on basis of text files would also be easier.


No, it dosn't. When you deal with a site with over 2000's translatable
strings on 4-5 different languages all they need/want is a tool that
optimizes their workflow (like trying the translation in the case of strings
with substitutions, searching strings, erasing, etc..) and many of them will
be just translators not addicts to vi/emacs power editing capabilities.

That's what I had when I built www.dinahosting.com, a massive site, with
just about 400000 lines of php code (it includes adodb & smarty code lines
too.. didn't exclude them from the counting) and well over 1000000 lines on
smarty templates some localized to different languages, etc..

--
Vicente Werner y Sánchez

My translation system works this way:

1.Subtemplate rendering. All translatable strings are marked for translation
and added to a list for later translation. (Here's where the block plugin
works)
2. Render the full page.
3. A filter works at this moment requesting all the translations from all
the needed strings and replacing all the marks with the translated strings.
4. The final page is then send to the browser for viewing.


On 5/31/06, Marcus Bointon <marcus@synchromedia.co.uk> wrote:
>
> On 31 May 2006, at 09:47, Vicente Werner wrote:
>
> > SELECT strSTRING,strTranslation FROM tblTerms WHERE coLanguage =
> > 'EN' and
> > strSTRING IN ('list','of','strings','to','collect');
>
> That's a nice way to do it. How do you get the list of strings? Do
> you have a plugin that pre-parses the current template for the
> translation keys so they are cached when the display tags request them?
>
> Marcus
> --
> Marcus Bointon
> Synchromedia Limited: Putting you in the picture
> marcus@synchromedia.co.uk | http://www.synchromedia.co.uk
>
>


--
Vicente Werner y Sánchez

On 31 May 2006, at 11:19, Vicente Werner wrote:

> 1.Subtemplate rendering. All translatable strings are marked for
> translation and added to a list for later translation. (Here's
> where the block plugin works)
> 2. Render the full page.
> 3. A filter works at this moment requesting all the translations
> from all the needed strings and replacing all the marks with the
> translated strings.

So your template blocks don't actually render the text - do you
render instead to some kind of intermediate tag that's easy to do a
regex for in your output filter? e.g. {{{translationid}}} How do you
pass the list of translations to the output filter? Do you stick it
in the $smarty instance?

Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk

In fact my intermediate text looks somethin' like this:

[|ORIGINAL_STRING_IN_CAPS|]

The plugin in fact does nothing than to communicate to the language
subsystem that it'll need that string to be translated to the current
session language.

The language subsystem is the one that keeps the list of strings, is the one
that requests them to the translation resource container, etc..

The filter uses the language subsystem full list to make the translation

On 5/31/06, Marcus Bointon <marcus@synchromedia.co.uk> wrote:
>
> On 31 May 2006, at 11:19, Vicente Werner wrote:
>
> > 1.Subtemplate rendering. All translatable strings are marked for
> > translation and added to a list for later translation. (Here's
> > where the block plugin works)
> > 2. Render the full page.
> > 3. A filter works at this moment requesting all the translations
> > from all the needed strings and replacing all the marks with the
> > translated strings.
>
> So your template blocks don't actually render the text - do you
> render instead to some kind of intermediate tag that's easy to do a
> regex for in your output filter? e.g. {{{translationid}}} How do you
> pass the list of translations to the output filter? Do you stick it
> in the $smarty instance?
>
> Marcus
> --
> Marcus Bointon
> Synchromedia Limited: Putting you in the picture
> marcus@synchromedia.co.uk | http://www.synchromedia.co.uk
>
> --
> Smarty General Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Vicente Werner y Sánchez