| Author |
 Topic  |
|
n/a
deleted
593 Posts |
 Posted - 29 August 2002 : 14:44:31
|
quote:
Taku,
As in just about everything, there is a trade-off between flexibility and performance. If you value flexibility the most, then certainly the DB approach is the best, with some compromises on performance. If you try to get a more balanced compromise, performance wise, the use of lang files is better, IMO. It still allows multi-language support and accounts for better performance than DB alone.
Agree on your point 100%...it's a design preference issue.
< |
Taku
|
 |
|
|
pweighill
Junior Member
United Kingdom
453 Posts |
Posted - 29 August 2002 : 17:08:56
|
quote:
Originally posted by bozden
b) Dividing the language files:
I did not decide on that. I'll look at the result. Probably I'll only take the admin part out, but who knows?
I you do split the files, how about 3 files.
- Standard Text
- Admin Text
- FAQ & Help Text
The FAQ & Help text would probably be quite long, and not needed for every page.< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 30 August 2002 : 05:25:37
|
| Yeah sure :) See the first page...< |
 Stop the WAR! |
|
|
|
pweighill
Junior Member
United Kingdom
453 Posts |
Posted - 07 September 2002 : 10:03:56
|
quote:
Originally posted by bozden
d) Define Global Strings (or Functions):
Please comment on these.
How about adding "Go To Top Of Page"?
(also in as "Go to Top of Page") in some files
It occurs a lot of times in the faq and pop_help files (although these could be reduced if a function was used to generate a faq/help item)< |
Edited by - pweighill on 07 September 2002 10:22:43 |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 07 September 2002 : 10:47:51
|
| I already have one function for that purpose and more than 130 global language variables defined as of now.< |
Stop the WAR! |
|
|
|
xmojmr
Starting Member
Czech Republic
1 Posts |
Posted - 07 September 2002 : 12:56:12
|
once the language dependant strings are isolated somehow (eg. by the L(<index>,<default value>) syntax suggested by ruirib), it is easy to write a preprocessor that will generate language versions for every language wanted.
as a result you get language specific version with NO run-time overhead. there is ONE core version that is to be edited and maintained. after a change you just run the preprocessor to generate language specific versions.
in case of a multilanguage site, the various language versions are to be placed in separate directories and the common entry point just switches to the proper language subdirectory looking at user's preference.
Appache server returns language variations of the same document in a similar way.
summary:
- ONE code to maintain
- run preprocessor (as part of install or something) to generate multiple variations
- NO run-time overhead
simple solution. needs just to separate the language strings. by list of named constants or special syntax structures. exact case doesn't matter.
my vote< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 07 September 2002 : 14:00:42
|
I see your point, but fortunately the overhead is not as large as you might think. In v4b03.x, 190,000 language strings are processed in 0.7 seconds. We need to take everything into account, including maintaining & distribution. In any case there is the problem of versioning and translations.
With v4 final, it will be the only code that will be kept anyway...
< |
Stop the WAR! |
|
|
|
Topic |
|
Forum Locked
