Bilingual site, best practice?

[Tim]

I am doing a small asp webshop and want to make it atleast bi-lingual.
I have thought of a few ways to do this but would like to have a second
opinion on what you think is the best way.

I have browsed the Google archives and seen this question pop up a few
times before but never with any particulary good answers. For some
reason this doesn't seem like a hot topic.

I am not talking about the product information, that is already stored
in multiple languages in the database. I am asking about the other texts
on the webpage, the linknames, the introduction the page descriptions etc.

My current ideas are as follows:
1. Many small arrays in one big file.
I create an includefile that looks like this

Dim INTRO = ("En bra sida", "A good page")
Dim LINKS = ("Länkar", "Links")

This will be a large but not huge file that is included with every other
page. and I reffer to each text like this

response.write( INTRO(lang))

This will make it easy to maintain, easy to understand and fast but it
will possibly be a memmory hog?

2. The second alternative is similar but use a different includefile for
each aspfile on the site. This will improve the memmory problems but
will decrease the maintainability .

3. Load all the text to the application object.
In global.asa I load all the textarrays into the application object and
retrieve them from there in each subsequent page.
This will certainly improve memmory effisiency but instead I have to do
a number of lookups in the application object on each page, someting
like this in global.asa:

application("IN TRO") = ("En bra sida", "A good page")
application("LI NKS") = ("Länkar", "Links")

All the subsequent pages will then look like this:
response.write( application("IN TRO")(lang))

A little bit uglier code and certainly slower then the first alternative
but more memmory efficient.

4. Database
The website curently relies un Access databases (for a number of
reasons) and I could of course create a language database and do lookups
there all the time.
This would cause some overhead for all the lookups but the
maintainability would be very high, just one simple database to keep an
eye on and update.

Any pointers to discussions on the subject or information on "best
practice" in the asp community would be much appreciated. I am sure all
the solutions are doable I would ratehr get it right the first time
instead of changing it later.

Tim

[Patrice]

Actually it doesn't matter. The key point IMO is to define how you'll access
the needed text. IMO you shoudl't access directly to a variable but should
use a function with the resource "key". as an argument. After the
implemention of this resource retrieving function could be whatever you want
(and y'oull be abelt o change it at will).

Generally you'll have likely to balance between speed and memory. Keeping
this in memory will be much faster (but will use some memory note though
that you can predict the amount of memory you'll use).
Then the exact storage depends on wether you need to have this handled by a
developer of if the application administrator should be able to change
this.. Note that event if you are storing in the database you could "cache"
this information in memory.

Patrice

--

"Tim" <al@gahnstrom.s e> a écrit dans le message de
news:gR******** ***********@new sb.telia.net...

I am doing a small asp webshop and want to make it atleast bi-lingual.
I have thought of a few ways to do this but would like to have a second
opinion on what you think is the best way.

I have browsed the Google archives and seen this question pop up a few
times before but never with any particulary good answers. For some
reason this doesn't seem like a hot topic.

I am not talking about the product information, that is already stored
in multiple languages in the database. I am asking about the other texts
on the webpage, the linknames, the introduction the page descriptions etc.

My current ideas are as follows:
1. Many small arrays in one big file.
I create an includefile that looks like this

Dim INTRO = ("En bra sida", "A good page")
Dim LINKS = ("Länkar", "Links")

This will be a large but not huge file that is included with every other
page. and I reffer to each text like this

response.write( INTRO(lang))

This will make it easy to maintain, easy to understand and fast but it
will possibly be a memmory hog?

2. The second alternative is similar but use a different includefile for
each aspfile on the site. This will improve the memmory problems but
will decrease the maintainability .

3. Load all the text to the application object.
In global.asa I load all the textarrays into the application object and
retrieve them from there in each subsequent page.
This will certainly improve memmory effisiency but instead I have to do
a number of lookups in the application object on each page, someting
like this in global.asa:

application("IN TRO") = ("En bra sida", "A good page")
application("LI NKS") = ("Länkar", "Links")

All the subsequent pages will then look like this:
response.write( application("IN TRO")(lang))

A little bit uglier code and certainly slower then the first alternative
but more memmory efficient.

4. Database
The website curently relies un Access databases (for a number of
reasons) and I could of course create a language database and do lookups
there all the time.
This would cause some overhead for all the lookups but the
maintainability would be very high, just one simple database to keep an
eye on and update.

Any pointers to discussions on the subject or information on "best
practice" in the asp community would be much appreciated. I am sure all
the solutions are doable I would ratehr get it right the first time
instead of changing it later.

Tim

[Tim]

Patrice wrote:

Actually it doesn't matter. The key point IMO is to define how you'll access
the needed text. IMO you shoudl't access directly to a variable but should
use a function with the resource "key". as an argument.

That indeed sound right.

I will go for a function L with an identifier parameter and use
Application variables to store the texts for now.

Thanks

Tim