| Vicente Werner 2006-05-31, 4:13 am |
| 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 XXXXin
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
|