Menu
▾
▴
phpwebsite-developers
|
From: Matthew M. <ma...@tu...> - 2002-03-20 16:54:03
|
Greetings again, As I work on the new core, it was decided to switch to modular updates. In other words, portions of the web site can be upgraded instead of the whole package. The admin can check for updates via an internal interface. The core would check the version file indicated by the module install. If an update exists, the admin downloads it and runs the update. All very nice but there is one problem: the translation system. The current translation system upgrades the package as a whole and it seems unwieldy for the new schema. So I am proposing this for CONSIDERATION. A new system would work much like the Calendar translation works. There could be an array of translations in the form of LANG_modulename. echo LANG_modulename["ten_charac"]; The core would session the array beforehand and load the appropriate translation file indicated by the core. The file would only be loaded once. The module would echo the element that sits in the index position. I am thinking the index would be the first 10 characters of the language the developer speaks: another plus for non-English speaking developers. It could also be a number, depending on responses to this letter. I figure an associative array would be just as fast as a numerically indexed array but I'm not sure. In any case, an associative array would be easier to read. I would also program a 'translation' module. That way a developer can assign users to the upkeep of different language files. It would keep track of additions and deletions and would point out incomplete language files before release. When the release is sound, the module would write the module's translation file. What I would like is input from anyone who develops international code. The reason we chose the preprocess route was speed. I want to know if this proposed system would cause delays or too much overhead. I would think that since your instructional text is usually brief, the memory concerns would be negligible. Let me know what you think by replying back to the list. Thanks for your time, Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: <bo...@el...> - 2002-03-20 17:51:36
|
I appreciate your asking for input. I hope these thoughts are
helpful:
I think we need multiple language files, not just one big one.
The english file is 112,000 bytes today. I'm not sure how that would
translate into memory usage. Maybe about half that.
But as features and modules are added, it could get to be ten times
its current size. Also, not all things will be short.
How about instructions for instance? They can get detailed.
I'd like to suggest that there be multiple files, and that
one definition inside that file would indicate that it
has already been loaded.
$lang_loaded["books"] = "yes"; //module is called "books"
This way, we only load what is needed.
If not ($lang_loaded["books"]) {
include 'books_file'
}
There should also be a local overide file, so that site operators
can tailor some of the messages without changing the released
files:
If ( !$lang_loaded["local_stuff"] )
&& file_exists('local_language_mods')
{
include ('local_language_mods') ;
} else if (!{$lang_loaded["local_stuff"])) {
//to avoid checking for the file again
$lang_loaded["local_stuff"]="yes"
}
It would be nice also if we had a file of generic translations for
things like "Submit", "Delete", "Are you Sure".
I have not yet used session_register to save arrays. If this can
be done, then I like the use of arrays. What is the syntax for
registering an array? Is it the same as registering any other
variable?
I assume you will be writing a function to do this. The call to the
function should also pass the option to force a reload:
load_translation('books','')
load_translation('books','reload') would force a reload.
Bob T.
|
|
From: Matthew M. <ma...@tu...> - 2002-03-20 18:08:03
|
> I'd like to suggest that there be multiple files, and that
> one definition inside that file would indicate that it
> has already been loaded.
> $lang_loaded["books"] = "yes"; //module is called "books"
> This way, we only load what is needed.
>
> If not ($lang_loaded["books"]) {
> include 'books_file'
> }
Agreed. Think about this too:
1) all module language files are loaded at once.
2) Only the active modules language files are loaded.
a)They are unloaded when not in use.
b)They are kept in memory until user logs off.
Which is fastest/smarter?
1) All loaded at once and then never again is one file hit but more memory
2) More file hits, less overhead
a) Even less overhead
b) More overhead but no more file hits
This may be an exercise in minutia but I am interested in 'the best way'.
> There should also be a local overide file, so that site operators can
> tailor some of the messages without changing the released
> files:
Good point. I'll make sure that is in the translate module as you may have
different translations within the same language.
> It would be nice also if we had a file of generic translations for
> things like "Submit", "Delete", "Are you Sure".
Ya I was thinking about this. Consider also that a programmer may program
in Spanish and we use an English translation. The generic translation file
becomes useless if the Spanish speaker could care less about English =)
Maybe a combination? Not sure yet.
> I have not yet used session_register to save arrays. If this can be
> done, then I like the use of arrays. What is the syntax for
> registering an array? Is it the same as registering any other
> variable?
Yes.
> I assume you will be writing a function to do this.
Not sure yet. For developer simplicity, I like the idea of just entering:
echo LANG_modulename["trans_this"]
instead of
$core->translate(LANG_modulename["trans_this"])
Kind of like calendar but with the language mod doing the work behind the
scenes.
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493
ICQ: 141057403
|
|
From: Karsten D. <k.d...@fi...> - 2002-03-21 11:51:38
|
On Mit, Mär 20, 2002 at 11:57:20 -0600, bo...@el... wrote:
> I'd like to suggest that there be multiple files, and that
> one definition inside that file would indicate that it
> has already been loaded.
> $lang_loaded["books"] = "yes"; //module is called "books"
> This way, we only load what is needed.
>
> If not ($lang_loaded["books"]) {
> include 'books_file'
> }
Ahem. Did you know about include_once() and it's sister
require_once()? There are even functions to query for all
included/required files. This should solve the problem better and
faster...
Regards,
Karsten
--
fishfarm netsolutions - Karsten Dambekalns
Echternstraße 73 - 38100 Braunschweig
Tel. +49 531 1232902 k.d...@fi...
Fax. +49 531 1232906 http://www.fishfarm.de/
-----------------------------------------------------
|
|
From: <bo...@el...> - 2002-03-21 14:19:57
|
Karsten -
include_once and require_once are used to ensure that files are not
loaded more than once while the server is responding to a single
request. We want to include the files only once per session. The
variables need to survive across multiple page requests. For this,
we need a session variable, hence:
$lang_loaded["books"] =3D"yes"
Thanks for the tip though.
On 21 Mar 2002 at 12:51, Karsten Dambekalns wrote:
> On Mit, M=E4r 20, 2002 at 11:57:20 -0600, bo...@el... wrote:
>
> > I'd like to suggest that there be multiple files, and that
> > one definition inside that file would indicate that it
> > has already been loaded.
> > $lang_loaded["books"] =3D "yes"; //module is called "books"
> > This way, we only load what is needed.
> >
> > If not ($lang_loaded["books"]) {
> > include 'books_file'
> > }
>
> Ahem. Did you know about include_once() and it's sister
> require_once()? There are even functions to query for all
> included/required files. This should solve the problem better and
> faster...
>
> Regards,
> Karsten
> --
> fishfarm netsolutions - Karsten Dambekalns
> Echternstra=DFe 73 - 38100 Braunschweig
>
> Tel. +49 531 1232902 k.d...@fi...
> Fax. +49 531 1232906 http://www.fishfarm.de/
> -----------------------------------------------------
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
|
|
From: Joel K. <jo...@jo...> - 2002-03-21 14:38:34
|
Random thought: What about having an option to "compile" the language into the files at install so that a webmaster that only needs to worry about one language (me and English) can do that and get the associated performance benefit AND making it easier/straightforward to work with the files. I have a feeling that nearly all of us only worry about one language, whatever that may be so this type of feature would benefit a lot of people. Joel |
|
From: Karsten D. <k.d...@fi...> - 2002-03-21 15:30:27
|
On Don, Mär 21, 2002 at 08:25:46 -0600, bo...@el... wrote: > request. We want to include the files only once per session. The > variables need to survive across multiple page requests. For this, > we need a session variable, hence: > $lang_loaded["books"] ="yes" So you want to keep the language stuff in the users's session? Hmm... okay. Then there is no other way. Regards, Karsten -- fishfarm netsolutions - Karsten Dambekalns Echternstraße 73 - 38100 Braunschweig Tel. +49 531 1232902 k.d...@fi... Fax. +49 531 1232906 http://www.fishfarm.de/ ----------------------------------------------------- |
|
From: Bob T. <bo...@el...> - 2002-03-21 17:01:37
|
I think this could be accomplished with the current make_disto script, with some tweaks. Just change the search so it looks for the function or variable call $lang_[] instead of TRANSLATE[[]]. On 21 Mar 2002 at 7:40, Joel Kleppinger wrote: > Random thought: > > What about having an option to "compile" the language into the files > at install so that a webmaster that only needs to worry about one > language (me and English) can do that and get the associated > performance benefit AND making it easier/straightforward to work with > the files. > > I have a feeling that nearly all of us only worry about one language, > whatever that may be so this type of feature would benefit a lot of > people. > > Joel > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Bob Treumann, 651-603-1245 Elmwood Solutions Inc. (St. Paul, Minnesota) bo...@el... http://www.elmwood.com ORACLE Business Alliance Program Member |
|
From: Karsten D. <k.d...@fi...> - 2002-03-21 11:51:38
|
On Mit, Mär 20, 2002 at 12:49:33 -0500, Matthew McNaney wrote: > Greetings again, > > As I work on the new core, it was decided to switch to modular updates. In > other words, portions of the web site can be upgraded instead of the whole > package. The admin can check for updates via an internal interface. The > core would check the version file indicated by the module install. If an > update exists, the admin downloads it and runs the update. > > All very nice but there is one problem: the translation system. > > The current translation system upgrades the package as a whole and it seems > unwieldy for the new schema. So I am proposing this for CONSIDERATION. I hope you dig through the old mail. There have at least been two occasions when the translation system was discussed, at that time mainly with having on-the-fly language switching and the pros and cons of this. I hope the new system (however it will look) will support this. I must admit that I am too lazy to look up the mgs-ids of the relevant mails right now. But a search on your mailbox file (you do keep the mails, don't you?) should reveal the stuff. I was into the discussion both times, so it might be enough to search for my name. If needed, I can of course look up the messages and post pointers or forward them to you directly. Regards, Karsten -- fishfarm netsolutions - Karsten Dambekalns Echternstraße 73 - 38100 Braunschweig Tel. +49 531 1232902 k.d...@fi... Fax. +49 531 1232906 http://www.fishfarm.de/ ----------------------------------------------------- |
|
From: Randall H. W. <rh...@ea...> - 2002-03-21 23:19:21
|
Regarding the new language constructs:
I have this week been (mostly to exercise my PHP muscles) a translation
database maintenance module for 0.8.x (The purpose was that the ??.pp files
could be generated from a database before building phpWebSite and that
anyone could suggest translations although a maintainer would need to
approve suggestions before they are included in the builds).
I'll have it done this weekend.
Right now it uses mod_translation_* for its own purposes and
i18n_translation_modname and i18n_translation_core for the translation
tables.
It includes an i18n (internationalization/localization) class that can
handle translations and maybe in the future other
internationalization/localization tasks (like numerical and date/time
formatting).
The current call is $i18n->translate($string). By including the function in
a class, I can cache translation calls to reduce the number of db
calls...but call the db to translate any string required...
I can think of a couple of reasons to store the translations in the
database:
1) files full of code do not have to be maintained.
2) translations can be updated off the web without having to download, FTP
and install a file.
3) translations do not have to sync with the English updates. Code can be
updated, patched, whatnot and translations can come later, if need be...
I hope you find this rambling helpful...
--
Randall Wood
rh...@ma...
|
|
From: Karsten D. <k.d...@fi...> - 2002-03-22 11:18:25
|
On Don, Mär 21, 2002 at 06:21:20 -0500, Randall Hansen Wood wrote: > Regarding the new language constructs: [...] > I can think of a couple of reasons to store the translations in the > database: > 1) files full of code do not have to be maintained. > 2) translations can be updated off the web without having to download, FTP > and install a file. > 3) translations do not have to sync with the English updates. Code can be > updated, patched, whatnot and translations can come later, if need be... 4) We use the database for every page call anyway. So the impact wouldn't be that bad. If you combine with the mentioned cacheing, this would be cool. Just my 2 cents, Karsten -- fishfarm netsolutions - Karsten Dambekalns Echternstraße 73 - 38100 Braunschweig Tel. +49 531 1232902 k.d...@fi... Fax. +49 531 1232906 http://www.fishfarm.de/ ----------------------------------------------------- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X