Ask Question Forum:
Model Library:2025-02-08:A.I. model is online auto reply
C
O
M
P
U
T
E
R
2
8
Show
#
ASK
RECENT
←
- Underline
- Bold
- Italic
- Indent
- Step
- Bullet
- Quote
- Cut
- Copy
- Paste
- Table
- Spelling
- Find & Replace
- Undo
- Redo
- Link
- Attach
- Clear
- Code
Below area will not be traslated by Google,you can input code or other languages
Hint:If find spelling error, You need to correct it,1 by 1 or ignore it (code area won't be checked).
X-position of the mouse cursor
Y-position of the mouse cursor
Y-position of the mouse cursor
Testcursor
caretPos
Attachment:===
Asked by bbdesign
at 2024-07-28 08:36:14
Point:500 Replies:10 POST_ID:829137USER_ID:11863
Topic:
Active Server Pages (ASP);;WordPress
I have a multi-language website setup to work something like this:
1. Each ASP page (or HTM page running as ASP on the server) has an include file that handles the translations
2. The include file determines the language of the user based on their login ID
3. A database table holds all of the language translations, which are organized by the page displaying the text
4. The script pulls in all of the translations that are relevant to the page calling the script, and populates an ASP dictionary object
5. The page itself then displays the translations by writing the contents of the dictionary object in the appropriate place in the markup, which looks like this:
<div id="example"><% =t.item("text_placeholder") %></div>
This has worked well for several years. But one of the issues is that we are ending up translating the same things multiple times. This site has a lot of little, intricate translations positioned throughout the markup, rather than just a few large, paragraph-format translations. So common translations such as "submit now", "first name", "continue", "January", "February", "Monday", "Tuesday", etc. are a hassle for the people who are handling the translations.
When I designed the system, I wanted to populate as few Dictionary entries as possible. There are dozens of pages in the site, so I didn't want to populate 500 translations when only 12 are needed for a given page. It is my understanding that these objects are held directly in system memory on the server, so that just sounds like a waste of system resources.
Now, my client (who uses the system and handles the actual translations) thinks having it broken up into multiple pages is too cumbersome to maintain. So I could just as easily populate every translation that exists into the Dictionary object, then they would all be available, whether they are used or not.
I don't know what effect that would have on performance, on the server, etc. Perhaps none!
I am looking at how WordPress handles translations, I don't know if what they are doing would be considered Best Practices in this case or not. But as far as I know, when you call a request for a translation, it is readily available (i.e., its already been pulled from the database?). So they are populating their translation object with everything in the system ahead of time?
Since it is all text, maybe the server load issue isn't that big a deal, it just sounds like overkill to pre-load that much data that you aren't going to use at all.
Anyway, would really appreciate any advice on how best to proceed.
Thank you!
1. Each ASP page (or HTM page running as ASP on the server) has an include file that handles the translations
2. The include file determines the language of the user based on their login ID
3. A database table holds all of the language translations, which are organized by the page displaying the text
4. The script pulls in all of the translations that are relevant to the page calling the script, and populates an ASP dictionary object
5. The page itself then displays the translations by writing the contents of the dictionary object in the appropriate place in the markup, which looks like this:
<div id="example"><% =t.item("text_placeholder") %></div>
This has worked well for several years. But one of the issues is that we are ending up translating the same things multiple times. This site has a lot of little, intricate translations positioned throughout the markup, rather than just a few large, paragraph-format translations. So common translations such as "submit now", "first name", "continue", "January", "February", "Monday", "Tuesday", etc. are a hassle for the people who are handling the translations.
When I designed the system, I wanted to populate as few Dictionary entries as possible. There are dozens of pages in the site, so I didn't want to populate 500 translations when only 12 are needed for a given page. It is my understanding that these objects are held directly in system memory on the server, so that just sounds like a waste of system resources.
Now, my client (who uses the system and handles the actual translations) thinks having it broken up into multiple pages is too cumbersome to maintain. So I could just as easily populate every translation that exists into the Dictionary object, then they would all be available, whether they are used or not.
I don't know what effect that would have on performance, on the server, etc. Perhaps none!
I am looking at how WordPress handles translations, I don't know if what they are doing would be considered Best Practices in this case or not. But as far as I know, when you call a request for a translation, it is readily available (i.e., its already been pulled from the database?). So they are populating their translation object with everything in the system ahead of time?
Since it is all text, maybe the server load issue isn't that big a deal, it just sounds like overkill to pre-load that much data that you aren't going to use at all.
Anyway, would really appreciate any advice on how best to proceed.
Thank you!
Expert: Scott Fell (padas) replied at 2024-07-28 14:48:22
On my dedicated server, for the applications that require heavier usage of resources, I place them on their own app pool. That way if something does crap out, it is only for that app/domain. You can watch your resource monitor and see how things go.
What you are doing is not much different than how a shopping cart works.
What you are doing is not much different than how a shopping cart works.
Expert: Scott Fell (padas) replied at 2024-07-28 14:42:41
RE: #a40225183
This would not work as I was trying to explain. The script from the include files load first. So you can't pass data from main page to the include file. But you can go the other way around.
This would not work as I was trying to explain. The script from the include files load first. So you can't pass data from main page to the include file. But you can go the other way around.
Author: bbdesign replied at 2024-07-28 12:15:01
Regarding (2), this is what I had in mind:
<% translationList="tran1, tran2, tran3, tran4" %>
<!-- #INCLUDE FILE="_translations.asp" -->
Then within _translations.asp, have something like:
<%
set rs1=cn1.execute("select translation from masterlist where placeholder in (" & translationlist & ")")
populate each name/value pair in the Dictionary object
...etc
%>
<% translationList="tran1, tran2, tran3, tran4" %>
<!-- #INCLUDE FILE="_translations.asp" -->
Then within _translations.asp, have something like:
<%
set rs1=cn1.execute("select translation from masterlist where placeholder in (" & translationlist & ")")
populate each name/value pair in the Dictionary object
...etc
%>
Author: bbdesign replied at 2024-07-28 12:12:19
@Scott Fell (padas) - the Classic ASP response was for the other commenter. Thank you for your input, this is exactly what I wanted to know. I do already have a "case" statement similar to what you are suggesting in ASP. So I am not populating the Dictionary object with all of the languages, just a lot of translations that each individual page doesn't need.
We are on a totally dedicated server in this case. It is quite possible that I could open the existing system up to populate all of the translations, and we would not see anything noticeable in terms of server performance.
I realize that any Javascript (i.e., non-server-side) solution is going to potentially have a delay between when the page loads and when the translations happen.
My goal at the moment is to present my client with options, which you have helped me to do. I was not aware of DOM Storage at all. I'm not so keen on paying Google to handle this for us. But the Get Localization option sounds interesting, as well as simply maintaining our own jSON file.
I appreciate your help, thanks again!
We are on a totally dedicated server in this case. It is quite possible that I could open the existing system up to populate all of the translations, and we would not see anything noticeable in terms of server performance.
I realize that any Javascript (i.e., non-server-side) solution is going to potentially have a delay between when the page loads and when the translations happen.
My goal at the moment is to present my client with options, which you have helped me to do. I was not aware of DOM Storage at all. I'm not so keen on paying Google to handle this for us. But the Get Localization option sounds interesting, as well as simply maintaining our own jSON file.
I appreciate your help, thanks again!
Expert: Scott Fell (padas) replied at 2024-07-28 12:12:07
(2) If so, maybe my workaround (as written in my 2nd post here) is the next best option?
I don't know that I am totally clear on what you are saying, but do note that include files run before any other scripts run. If you declare a variable above the include statement, that variable will not be available in the include. You should do this all in one file and probably as a function.
Yes, it could be more work for you, but the outcome is better. That seems to be the way programming works.
I don't know that I am totally clear on what you are saying, but do note that include files run before any other scripts run. If you declare a variable above the include statement, that variable will not be available in the include. You should do this all in one file and probably as a function.
Yes, it could be more work for you, but the outcome is better. That seems to be the way programming works.
Expert: Scott Fell (padas) replied at 2024-07-28 11:58:57
I understand this is in classic asp. I still think the most efficient/fastest/use less (no) resources is using jquery or javascript. The javascript does not run until the html is rendered to t he browser.
(1) Is it a problem to populate the ASP Dictionary object with hundreds of translation values, when possibly only 10-15 will be used on a given page
It depends on your server/usage. If this is a high traffic site and you are on a small dedicated service / vps with limited resources, something will give. If you 5,000 or 10,000 visitors per month, this is very low and you probably will not have an issue.
Sticking with the server side I would still do a Select/Case for each language. This way you may still have 500 items, but you are only loading the 10 you need.
(1) Is it a problem to populate the ASP Dictionary object with hundreds of translation values, when possibly only 10-15 will be used on a given page
It depends on your server/usage. If this is a high traffic site and you are on a small dedicated service / vps with limited resources, something will give. If you 5,000 or 10,000 visitors per month, this is very low and you probably will not have an issue.
Sticking with the server side I would still do a Select/Case for each language. This way you may still have 500 items, but you are only loading the 10 you need.
Dim dSet d=Server.CreateObject("Scripting.Dictionary")Select CASE Language CASE "nl" ' Dutch d.Add "save","dutch for save" d.Add "continue","dutch for continue" d.Add "back","dutch for back" d.Add "quit","dutch for quit" CASE "fr" ' French d.Add "save","french for save" d.Add "continue","french for continue" d.Add "back","french for back" d.Add "quit","french for quit" CASE "es" ' Spanish d.Add "save","spanish for save" d.Add "continue","spanish for continue" d.Add "back","spanish for back" d.Add "quit","spanish for quit" CASE ELSE ' any language not covered ' add dictionary look up here probably englishEND Select 1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:24:25:26:
Author: bbdesign replied at 2024-07-28 10:37:54
This is Classic ASP.
I guess to simplify my question:
(1) Is it a problem to populate the ASP Dictionary object with hundreds of translation values, when possibly only 10-15 will be used on a given page?
(2) If so, maybe my workaround (as written in my 2nd post here) is the next best option?
I guess to simplify my question:
(1) Is it a problem to populate the ASP Dictionary object with hundreds of translation values, when possibly only 10-15 will be used on a given page?
(2) If so, maybe my workaround (as written in my 2nd post here) is the next best option?
Accepted Solution
Expert: Scott Fell (padas) replied at 2024-07-28 10:37:30
500 points EXCELLENT
To answer your question specifically, The way would handle this is to use one include file for your translations. When you have multiple include files and expecting something to happen inside an if/then statement you may run into trouble.
Select CASE Language CASE "nl" ' Dutch ' add dictionary look up here CASE "nl" ' Dutch ' add dictionary look up here CASE "fr" ' French ' add dictionary look up here CASE "es" ' Spanish ' add dictionary look up here CASE ELSE ' any language not covered ' add dictionary look up here probably englishEND Select 1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:
You can either hard code your dictionary objects or pull them from a database. Memory could be an issue. But you have to look at how many visitors/page loads the site gets as well if it is on a shared server or a dedicated or cloud.
For speed, it seems like this should really be done client side.
You can use local storage in place of your dictionary https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage . Works on all browsers http://caniuse.com/#search=localstorage
Or even a translate api https://developers.google.com/translate/ or http://www.getlocalization.com/library/api/get-localization-translation-api/ Or you can create a static json file with your key value pairs and use jquery getJson http://api.jquery.com/jquery.getjson/ to load the file you need and do the look up and replace.
Doing this client side would allow much greater performance because you are not asking the server to do this. I like the idea of the api, but if you want granular control, static json files for each language. If you continue doing this via asp, I like the idea of one include file with all the languages on one page, but just load the language you need at log in.
Let's say you like the idea of the static json file. I would create one for each language but store the data to update in a db. Then each time you save the db, write out a new json file via fso http://www.w3schools.com/asp/met_createtextfile_folder.asp
Expert: duncanb7 replied at 2024-07-28 09:25:57
Are you using ASP.NET ? if so, why it is issue ?
Could you tell me about your system information ?
Please advise
Duncan
Could you tell me about your system information ?
Please advise
Duncan
Author: bbdesign replied at 2024-07-28 08:51:07
I guess one possible workaround would be for me to put in the ASP page, before the include script is called, a list of translations that will be needed for the page. Then the script could only populate the Dictionary object with those translations. My client could still populate one large data table with translations, we won't waste server resources. The downside is that I have to insert the list of needed translations in the ASP pages, which adds work for me and makes the pages a little more difficult to maintain (in case someone other than me has to do this in the future).