| Author |
 Topic  |
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
 Posted - 29 March 2002 : 18:28:58
|
quote:
quote:
Performance is a recurring issue of discussion here. Any solution should take that into account.
So, flip back to page 1, post 1  .
Think PinkPost v40b03 Patches
You are right. This was started as a discussion on strategies to diminish server load...
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs< |
 |
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 29 March 2002 : 18:45:51
|
quote:
You are right. This was started as a discussion on strategies to diminish server load...
which is my point entirely, using a db method, every single visitor to the site could theoretically be viewing in a different language with no significant extra overhead than one language, this certainly could not be said the include/strings method.
< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 19:13:22
|
quote:
which is my point entirely, using a db method, every single visitor to the site could theoretically be viewing in a different language with no significant extra overhead than one language, this certainly could not be said the include/strings method.
What do you want to value the most as server load: CPU use, memory use?
What do you want to consider as overhead: once again, server resources, response time, DB access what?
There are different answers depending on how you look at the issues. It really has to do with what you deem acceptable. For a 1 GB RAM server with an Access DB you may prefer to have less DB access and more use of RAM. Everything is relative. For 10 languages simultaneoulsy, we would be talking a 1 MB RAM (if the original strings are removed as bozden suggested) for the include files. Is this meaningful? It can be, but as hardware improves (each time servers are more powerful) it won't mean that much. Also, there are good alternatives to have more than a single include file, diminishing even further the significance of the overhead in RAM use...
All in all what matters is finding the best balance between many (sometimes contradicting) factors. What can be good for ya, may not be the best for me and vice-versa...
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 28 August 2002 : 19:53:03
|
I decided to follow this:
a) We can get rid of the '"original string" part:
NO - I'll keep them as the ASP files are kept pre-compiled in IIS 5+
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?
c) Keeping track of files:
I'll decide on that after finishing everthing and running some simple performance tests on the data.
d) Define Global Strings (or Functions):
I started to use this. Currently there are 53 such strings. These will be stay as they are in the following releases. As they are "generic" to the forum application, also the MODs can use them. Here are the current ones:
sLng_Basic_ActiveTopic = "Active Topics" '"Active Topics"
sLng_Basic_AdminLogin = "Admin Login" '"Admin Login"
sLng_Basic_AdminSection = "Admin Section" '"Admin Section"
sLng_Basic_AllForums = "All Forums" '"All Forums"
sLng_Basic_AHRTopic = "Approve/Hold/Reject this Topic" '"Approve/Hold/Reject this Topic"
sLng_Basic_Author = "Author" '"Author"
sLng_Basic_BackToAdminHome = "Back To Admin Home" '"Back To Admin Home"
sLng_Basic_BackToForum = "Back To Forum" '"Back To Forum"
sLng_Basic_CategoryLocked = "Category Locked" '"Category Locked"
sLng_Basic_CloseWindow = "Close Window" '"Close Window"
sLng_Basic_ConfigPosted = "Configuration Posted!" '"Configuration Posted!"
sLng_Basic_Congratulations = "Congratulations!" '"Congratulations!"
sLng_Basic_DeleteForum = "Delete Forum" '"Delete Forum"
sLng_Basic_DeleteTopic = "Delete Topic" '"Delete Topic"
sLng_Basic_EditForumProperties = "Edit Forum Properties" '"Edit Forum Properties"
sLng_Basic_EditTopic = "Edit Topic" '"Edit Topic"
sLng_Basic_Forum = "Forum" '"Forum"
sLng_Basic_ForumLocked = "Forum Locked" '"Forum Locked"
sLng_Basic_HeldTopic = "Held Topic" '"Held Topic"
sLng_Basic_HotTopic = "Hot Topic" '"Hot Topic"
sLng_Basic_HotTopicWithNew = "Hot Topic with New Posts" '"Hot Topic with New Posts"
sLng_Basic_JumpToLastPost = "Jump to Last Post" '"Jump to Last Post"
sLng_Basic_LastPost = "Last Post" '"Last Post"
sLng_Basic_LockForum = "Lock Forum" '"Lock Forum"
sLng_Basic_LockTopics = "Lock Topic" '"Lock Topic"
sLng_Basic_LockedTopic = "Locked Topic" '"Locked Topic"
sLng_Basic_Login = "Login" '"Login"
sLng_Basic_Logout = "Logout" '"Logout"
sLng_Basic_Message = "Message" '"Message"
sLng_Basic_NewPosts = "New Posts" '"New Posts"
sLng_Basic_NewPostSinceLastLogon = "New posts since last logon" '"New posts since last logon"
sLng_Basic_NewTopic = "New Topic" '"New Topic"
sLng_Basic_NoNewPosts = "No New Posts" '"No New Posts"
sLng_Basic_Note = "NOTE:" '"NOTE:"
sLng_Basic_NTAccount = "NT Account" '"NT Account"
sLng_Basic_Off = "Off" '"Off"
sLng_Basic_OldPosts = "Old Posts" '"Old Posts"
sLng_Basic_On = "On" '"On"
sLng_Basic_Password = "Password" '"Password"
sLng_Basic_Read = "Read" '"Read"
sLng_Basic_Replies = "Replies" '"Replies"
sLng_Basic_ReplyToTopic = "Reply to Topic" '"Reply to Topic"
sLng_Basic_ResetOldValues = "Reset Old Values" '"Reset Old Values"
sLng_Basic_Send = "Send" '"Send"
sLng_Basic_SubmitNewConfig = "Submit New Config" '"Submit New Config"
sLng_Basic_Topic = "Topic" '"Topic"
sLng_Basic_TopicLocked = "Topic Locked" '"Topic Locked"
sLng_Basic_UnLockCategory = "Un-Lock Category" '"Un-Lock Category"
sLng_Basic_UnLockForum = "Un-Lock Forum" '"Un-Lock Forum"
sLng_Basic_UnLockTopic = "Un-Lock Topic" '"Un-Lock Topic"
sLng_Basic_UnModeratedTopic = "UnModerated Topic" '"UnModerated Topic"
sLng_Basic_Username = "Username" '"Username"
sLng_Basic_ViewUnmoderated = "View All UnModerated Posts" '"View All UnModerated Posts"
Please comment on these.
I'll look at the functions later...
e) Use of generic strings:
I'll also look at these later, after the collection of strings and decide on them one by one with native English speakers PLUS translators, because it may cause semantic problems in other languages. The only think I've done to change Username, UserName and User Name to Username.
Thats all for today boys and girls  .
< |
 Stop the WAR! |
|
|
|
n/a
deleted
593 Posts |
Posted - 28 August 2002 : 20:59:59
|
| Quickly going through the forum, I realized that there was a dsicussion on storing language strings in DB, which tends to be an approach to have a globalized DB driven dynamic multilingual web site... You are now pretty much applying to have Global/Local strings.. Did you/dev team explore further on DB approach (I think Huwr was mentioning)?< |
Taku
|
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
|
|
n/a
deleted
593 Posts |
Posted - 28 August 2002 : 23:14:27
|
Oh, OK. That's it then.  < |
Taku
|
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 August 2002 : 00:33:52
|
quote:
Originally posted by LeoRat
Quickly going through the forum, I realized that there was a dsicussion on storing language strings in DB, which tends to be an approach to have a globalized DB driven dynamic multilingual web site... You are now pretty much applying to have Global/Local strings.. Did you/dev team explore further on DB approach (I think Huwr was mentioning)?
Please re-read the test results by ruirib.< |
Stop the WAR! |
|
|
|
n/a
deleted
593 Posts |
Posted - 29 August 2002 : 04:42:52
|
quote:
Originally posted by bozden
quote:
Originally posted by LeoRat
Quickly going through the forum, I realized that there was a dsicussion on storing language strings in DB, which tends to be an approach to have a globalized DB driven dynamic multilingual web site... You are now pretty much applying to have Global/Local strings.. Did you/dev team explore further on DB approach (I think Huwr was mentioning)?
Please re-read the test results by ruirib.
Thanks. I re-read the posts carefully.. got the point. Am still curious as the test and assumption is for single language...whether it's in English, Portuguese, Chinese, or whatever.... Although I understand there is a diffferent perspective on language supports on the forum, there is no clear indication of how it may be in multilingual enviornment... Part of me tends to agree with Huwr as I know the best solution adopted for handling 10 Asian languages was to adopt a DB driven dynamic web site, where you can switch to any language in any level of the web site..but again this wasn't the forum or chat type envionrment but more of push-publishing model and used utf-8 as the standard encoding scheme both on client and server sides....
Am assuming that your usage of global/locale strings would help integrating MODS better in V4.4 as well, in addition to performance improvement for code execution?
< |
Taku
|
|
|
|
ajhvdb
Junior Member
Netherlands
392 Posts |
Posted - 29 August 2002 : 07:56:07
|
Didn't read the whole thread but I'd like to give you an example in ASP how we solved a similar problem
writing an application in COBOL and C+. The company wanted a Dutch language and a English language version.
We didn't want to upgrade 2 sources all the time so we decided to send a string to a dummy function with an ID attached.
Like:
Response.Write "<TD ALIGN=""LEFT"">" & L(45,"Hello World") & "<TD>"
The function looked like:
Function L(ByRef intID, ByRef strText)
L = strText
End Function
Now you see this doesn't use many resources and the developer didn't needed a fully named
variable "strHelloWorld", to understand where he/she is, in the source.
English language file looked like this:
1 = "Welcome"
2 = "Quit"
.
.
45 = "Hello World"
Dutch language file looked like this:
1 = "Welkom"
2 = "Einde"
.
.
45 = "Hallo Wereld"
When the application was ready we used a simple "Translate" program that did the following:
- Ask for language
- Look in the source "line by line" and find every L(????)
- get the ID.
- Look into a language file for this ID
- Replace L(45, "Hello World") with L(45, "Hallo Wereld")
- Save the new source file in a different directory.
- compile the source.
You could do something like this with the "standard forum source" because it doesn't make development for you english guys difficult.
- If you want an NL version of this forum. Start the "Translate" program and save in /ForumNL.
With a new Mod:
- A Mod developer claims an string ID range 4000 to 4100.
- I create an translation file in Dutch for this Mod and send it to the developer.
- Install the Mod.
- Add translated strings to language file.
- Start the "Translate" program once.
etc.
< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 August 2002 : 09:56:19
|
quote:
Originally posted by LeoRat
Thanks. I re-read the posts carefully.. got the point. Am still curious as the test and assumption is for single language...whether it's in English, Portuguese, Chinese, or whatever.... Although I understand there is a diffferent perspective on language supports on the forum, there is no clear indication of how it may be in multilingual enviornment... Part of me tends to agree with Huwr as I know the best solution adopted for handling 10 Asian languages was to adopt a DB driven dynamic web site, where you can switch to any language in any level of the web site..but again this wasn't the forum or chat type envionrment but more of push-publishing model and used utf-8 as the standard encoding scheme both on client and server sides....
Am assuming that your usage of global/locale strings would help integrating MODS better in V4.4 as well, in addition to performance improvement for code execution?
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.
< |
Snitz 3.4 Readme | Like the support? Support Snitz too |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 August 2002 : 10:01:41
|
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?
Probably the disadvantages of managing a great number of files are bigger than the advantages.
quote:
d) Define Global Strings (or Functions):
I started to use this. Currently there are 53 such strings. These will be stay as they are in the following releases. As they are "generic" to the forum application, also the MODs can use them. Here are the current ones:
Frankly, I think this must be more troublesome than it's worth, reasons same as before. I doubt that there are any performance advantages outta this.
quote:
e) Use of generic strings:
I'll also look at these later, after the collection of strings and decide on them one by one with native English speakers PLUS translators, because it may cause semantic problems in other languages. The only think I've done to change Username, UserName and User Name to Username.
Agree that you should try to strive for as much consistence as possible.
Let me know if you need any help on this task. Keep up the good work  .
< |
Snitz 3.4 Readme | Like the support? Support Snitz too |
Edited by - ruirib on 29 August 2002 10:04:52 |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 August 2002 : 12:11:26
|
quote:
Originally posted by ruirib
...
Rui,
with the language resource files increasing in size (more features => more files => more text) the effects will get larger. As v4 will be the base for any further release, we have to think of these case of 5000 different phrases also.
We think the same on (e), so let us leave it out for now.
(b) and (d) are somehow coupled into each other. Here are the reasons behind the decisions:
- From the site statistics of forum/snitz.com.forum (posted once by Huw), we know these:
quote:
Topic.asp 21%
default.asp 17%
forum.asp 11%
active.asp 10%
post.asp 4%
search.asp 1%
most of the other 30+% is image files
So more than 75% are caused from these 6 files.
- On a small site, these decisions does not matter at all, but with N (N is a large number) forum page views a week, it will have effects. There will be one or two admin page views in the same time period at most. So, if we take the admin strings separate and include them in admin files only, there will be a performance increase. Normal files will only include 1 file, admin files will include 2 files. I don't think to have 3-4 different files by now because of the reason you mentioned.
- There is the (important) psychological effect on a translator, when (s)he starts to re-translate the same string 10th time. We needed to hinder this somehow.
- If we use global strings like sLng_Basic_AllForums, and keep them same in the future, it will ease the work of development on base code AND mods. I didn't use something like sLng_Global00010, because it would mean a lookup.
- I extracted a couple files first before deciding on this. Here are the results for active.asp: 71 total strings, 29 active.asp only strings (27 separate), 42 global strings. As you can see, a good percent of them will be covered by global ones, and you get used to use them after a couple instances.
< |
Stop the WAR! |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 August 2002 : 12:47:59
|
Ok, I can completely understand that. I don't want to appear stubborn, I still think the overall burden is still small (look at my test data, 190000 string assignments were made under .7 secs), but I can accept that decision.
I agree that if you keep only 3 or 4 files, they may be easier to handle, translation wise, as you state.< |
Snitz 3.4 Readme | Like the support? Support Snitz too |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 August 2002 : 14:19:20
|
quote:
Originally posted by ajhvdb
Didn't read the whole thread but I'd like to give you an example in ASP how we solved a similar problem
writing an application in COBOL and C+. The company wanted a Dutch language and a English language version.
Thank you for sharing this info with us. In fact I also thought about a similar strategy at the very start, but left that because of several reasons.< |
Stop the WAR! |
|
|
|
Topic |
|
Forum Locked
Nathan Bales