Menu
▾
▴
phpwebsite-developers — For our development team.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
(265) |
Apr
(166) |
May
(25) |
Jun
(17) |
Jul
(20) |
Aug
(47) |
Sep
(6) |
Oct
(14) |
Nov
(66) |
Dec
(64) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(109) |
Feb
(64) |
Mar
(34) |
Apr
(23) |
May
(64) |
Jun
(9) |
Jul
(13) |
Aug
(6) |
Sep
(33) |
Oct
(272) |
Nov
(67) |
Dec
(75) |
| 2003 |
Jan
(264) |
Feb
(244) |
Mar
(171) |
Apr
(119) |
May
(54) |
Jun
(93) |
Jul
(51) |
Aug
(48) |
Sep
(14) |
Oct
(49) |
Nov
(47) |
Dec
(15) |
| 2004 |
Jan
(13) |
Feb
(27) |
Mar
(18) |
Apr
(44) |
May
(35) |
Jun
(24) |
Jul
(39) |
Aug
(142) |
Sep
(35) |
Oct
(34) |
Nov
(49) |
Dec
(24) |
| 2005 |
Jan
(60) |
Feb
(71) |
Mar
(19) |
Apr
(27) |
May
(68) |
Jun
(4) |
Jul
(30) |
Aug
(10) |
Sep
(23) |
Oct
(24) |
Nov
(13) |
Dec
(6) |
| 2006 |
Jan
(4) |
Feb
(46) |
Mar
(64) |
Apr
(18) |
May
(16) |
Jun
(37) |
Jul
(7) |
Aug
(19) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(23) |
| 2007 |
Jan
(25) |
Feb
(21) |
Mar
(32) |
Apr
(36) |
May
(12) |
Jun
(1) |
Jul
(7) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: <bo...@el...> - 2002-03-09 21:13:52
|
I added two new directories to phpWebsite. These are placeholder directories with zero content except a README file. This is not a new feature ( I know its too late..), but a bug fix to menu, and a preparation for future use. the "local" directory is indented for site administrators to put their own stuff and know that phpWebsite will never step on it by using the same name. All we have to do in this directory is to leave it empty. The "bridge" directory is a placeholder for later installation of CMS Bridge middleware. The new version of menu.php checks to see if the url begins with "http" or "local" or "bridge". It it does, it leaves the url unaltered. Before, this check just tested for "http:', but added a "menu=<integer> parameter to everything that had a relative path. The menu= parameter had the potential to conflict with "menu" paramaters needed by the called application. Bob T. |
|
From: Joel K. <jo...@jo...> - 2002-03-08 18:09:18
|
I like seeing that comments threading indentation is finally being properly addressed and fixed in .8.2. I was just about to put in this email that I was going to fix it, and I'm glad to see I don't have to. :) The only comment I have is about how the nesting is currently done. It can be done much more professionally by changing just a few tags. Currently, this is the setup: <blockquote> <a href="link-to-first-toplevel-comment">Comment Title</a> by AUTHOR on DATE-TIME<br /><br /> <blockquote> <a href ="link to first secondlevel comment"> etc. .. </blockquote> <blockquote> <a href="link-to-second-toplevel-comment">Comment Title</a> by AUTHOR on DATE-TIME </blockquote> .. </blockquote> First, I don't see any point for having <br /> in there at all. It just spreads it out. Second, blockquote (at least by default. I haven't found a way to modify it) adds a double-spaced line in between each entry, which makes the page twice as big. My suggestion is to use <ul><li> to get the <br> effect. It's not quite as clean in the code, but it looks much better (this is the way slashcode does its comments). So the new version would look like this: <ul><li> <a href="link-to-first-toplevel-comment">Comment Title</a> by AUTHOR on DATE-TIME <ul><li> <a href ="link to first secondlevel comment"> etc. .. </ul></li> <li> <a href="link-to-second-toplevel-comment">Comment Title</a> by AUTHOR on DATE-TIME </li> .. </ul></li> IMO, that looks a LOT cleaner. At any rate, the indention is a great start, at the very least. One other thing to add would be the Score variable in the Comment link (again, as slashdot does). I look forward to seeing this implemented. Alternatively, I can implement it without any trouble. Joel |
|
From: Jeremy A. <ja...@tu...> - 2002-03-07 00:50:09
|
Just in case some one has questions about why we jumped from somewhere in the 50's to about 500 some on SF stats today. The SF stats system has a bug. Stats are still getting gathered correctly and it will be fixed soon. See http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#stats -- Jeremy Agee phpWebSite Development Team (http://phpwebsite.appstate.edu) Appalachian State University phpEasyAdmin (http://easyadmin.sourceforge.net) |
|
From: Matthew M. <ma...@tu...> - 2002-03-05 22:06:49
|
Greetings, As a birthday gift to all you helpful developers I have added the important 'multisite' file to the CVS copy. Look for multisite_readme.php for instructions. Multi site seems to work with one exception: all old modules do not work with it so the 'spoke' site is fairly boring. You can log in and play with the standard modules written for the core. Old modules can (and will) be updated to work eventually, so hang tight. As for what multisite does. It allows you to run several sites off one base of code. The only files that the 'spoke' needs are their themes and box files. You can run the other site on a separate database or (if you fillout the database config files correctly) on the same one. Anyway, I hope this will help answer the question of WHY we feel the need to write a new core. Think: 20 sites upgraded = 1 set of code. Pretty nice eh? Best regards, Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Mike N. <mh...@us...> - 2002-03-03 17:27:54
|
At 2002-03-03 11:12 -0600, bo...@el... wrote: >Also, if anyone has other ideas of things I could check for. Please >include the code snippet to do the check, if you can. Prior to an upgrade, check for cruft in the database (e.g. tables that are obsolete, or not associated with a module). Notify admin if there is a problem, and refuse to update. Prior to upgrading an installation, check all database tables that will be modified. If one of the tables is bad notify the admin, and refuse to update. CHECK TABLE tbl_name CHECK TABLE tbl2_name etc. Optimize tables after changing/modifying their structure. OPTIMIZE TABLE tbl_name -- Mike Noyes <mh...@us...> http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000&page_id=4 |
|
From: <bo...@el...> - 2002-03-03 17:08:18
|
I am trying to build more tests into the diagnostics of ask_install.php. The more diagnostics we have the less time we spend chasing down things that look like bugs but are really installation or configuration errors. If I knew how, I would check for these conditions: 1 PHP v4.0.6 or higher ? 2 PHP session support compiled in? 3 register globals set to ON ? 4 PWS Version, to identify need for upgrade. Compare existing version of schema to version of files. If anyone can tell me how to do these checks, I'll add it to the code. Also, if anyone has other ideas of things I could check for. Please include the code snippet to do the check, if you can. At this point, it checks to see if the password has been changed from the default in config.php (indicating the config file has not been changed) and for correct directory "write" permissions. |
|
From: Alessandro P. (T. / J578) <al...@ti...> - 2002-03-02 13:51:32
|
On Sat, 2002-03-02 at 01:43, Michael Dearman wrote: > > I haven't installed PWS yet, but was trying to find some docs that might > address installation with security in mind. > > Also, as I understand it, having register_globls on isn't the most secure thing to do. Any > comments? This is known and it will be addressed in 0.8.3 > And, I would suppose trying to use php's safe_mode won't work. You suppose WRONG: phpWebSite perfectly works with safe_mode=On. Infact I use safe_mode=on on my delevelopment box > Just any pointers would be appreciated. Bye, Alessandro -- Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087 phpWebSite Development Team http://phpwebsite.appstate.edu INWO Project coordinator http://inwoproject.sourceforge.net "I will carry you through, hicking and screaming, and in the end you will thank me" - Tyler Durden [from "Fight Club"] |
|
From: Michael D. <mde...@in...> - 2002-03-02 00:34:45
|
I haven't installed PWS yet, but was trying to find some docs that might address installation with security in mind. Also, as I understand it, having register_globls on isn't the most secure thing to do. Any comments? And, I would suppose trying to use php's safe_mode won't work. Just any pointers would be appreciated. Thanks, MD |
|
From: Bob T. <bo...@el...> - 2002-03-01 01:18:54
|
Some of you have tried the screen that I wrote that diverts a person to an install script if they try to run phpWebsite without running setup. The diagnostics on this screen are all in English. I think all the other install instructions in README and docs/ files are also in english. I am ready to pretty up this screen prior to the 8.2 release. I would also like to change the documentation that tells people: " 5. phpWebSite has a completely web-based install - point your browser to: http://your_phpWebSite_powered_site.com/setup/ and follow the onscreen instructions. I want to change it so it tells them to go to: http://your_phpWebSite_powered_site.com I want to continue to work on the diagnostics and explanations on this screen, but if I put everything in TRANSLATE[[]] statements, it will make updates, clarifications and additions quite difficult. I think the difficulty of doing this would lead to the screen containing lots less helpful information than it would otherwise. I would like to just leave this screen in English, at least until such time until all the other README and documentation files are put into multiple languages. While websites have many users who do not speak English, it is hard to see how someone who cannot read English would be able to install and maintain a phpWebsite, since all the instructions and support forums are in English. For this reason I think it would be OK to present the diagnostic screen in English only. It is only seen by the admin. ============================================= Question One: Can I leave this screen in English only? Question Two: Can I change the documentation to point users to this screen for install? ============================================ -- Bob Treumann, 651-603-1245 Elmwood Solutions Inc. (St. Paul, Minnesota) bo...@el... http://www.elmwood.com ORACLE Business Alliance Program Member |
|
From: Matthew M. <ma...@tu...> - 2002-02-28 21:55:41
|
Hello all, Remember that Friday is FEATURE LOCKDOWN. No more new stuff after Friday so we can release a release candidate on Monday or Tuesday. If you are saying to yourself 'Just a little more time Matt' recall we have not had a release since October. That is a while. BUT THAT DOES NOT RELIEVE YOU FROM YOUR RESPONSIBILITIES FOR THIS MATERIAL! I'm waiting for reports from some of you. Listen, I'm not joking! This is my job! Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Alessandro P. (T. / J578) <al...@ti...> - 2002-02-28 20:22:00
|
On Thu, 2002-02-28 at 19:54, spiggy wrote: > Is there a real need to have 'Ok' and 'Ok!' and 'OK' as separate > entries? Or separate entries for 'Votes', 'votes' and 'votes:'? There > are also a lot of similar examples. > > I know it does not have any difference as far as the runtime speed but > the language files seem to be in the midst of a slight chaos right now. > is this something that should be fixed before the next release? > > spiggy A cleanup for some entries is planned currently for 0.8.3 Btw I will need to ask developers of each module involved (of course) :) Bye, Alessandro -- Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087 phpWebSite Development Team http://phpwebsite.appstate.edu INWO Project coordinator http://inwoproject.sourceforge.net "I will carry you through, hicking and screaming, and in the end you will thank me" - Tyler Durden [from "Fight Club"] |
|
From: spiggy <th...@me...> - 2002-02-28 19:51:53
|
Is there a real need to have 'Ok' and 'Ok!' and 'OK' as separate entries? Or separate entries for 'Votes', 'votes' and 'votes:'? There are also a lot of similar examples. I know it does not have any difference as far as the runtime speed but the language files seem to be in the midst of a slight chaos right now. is this something that should be fixed before the next release? spiggy |
|
From: root <ro...@bi...> - 2002-02-28 19:18:12
|
hey people - just thinking.. would it be a useful thing if there was a $secure_url variable in config.php that you'd be (optionally) redirected to when you access the admin interface?... later, Vlad |
|
From: Matthew M. <ma...@tu...> - 2002-02-27 13:20:57
|
Salutations, We are getting close to our Release Candidate. However, looking at the bug reports for Alessandro's last snapshot, we have a little farther to go. So, lets not commit anything new. Work on the current CVS and try to get it bug free. No new features. If there is something you feel needs to trump this, contact Brian or myself. Let's try for a Release Candidate for the beginning of next week after the next series of bug fixes. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Adam M. <ad...@tu...> - 2002-02-26 06:43:53
|
I added in a few things to the current cvs core. The userpage module now implements a new table called mod_userpage_related. This table allows for modules to relate things to userpages and maybe do something upon viewing these pages. The modules who want to implement this feature have to add a text column roughly named "module_id" to the table which will store a serialized array of ids or other identifiers for the object. Example (Documents Manager): ALTER TABLE mod_userpage_related ADD fileman_id text DEFAULT NULL; The Web Links module should soon be implementing the table as well. I also fixed a minor bug in the module installer that didn't allow modules to have their module_uninstall.php file directly executed. It always defaulted to the $op=uninstall way. Adam --------------------------------- Adam Morton Developer - Web Technology Group Appalachian State University ad...@tu... |
|
From: <bo...@el...> - 2002-02-26 04:40:46
|
I can't seem to add a file to the CVS. What this file does is to redirect the user to the documentaion or to the setup if they try to launch their site without running setup first. I added one before, and it worked nice, now it keeps telling me this: [snip] add phpwebsite/setup/ask_install.php cvs add: in directory .: cvs [add aborted]: there is no version here; do 'cvs checkout' first Well, the file exists locally, and I did do a checkout so what is wrong? Any clues? Maybe my path is wrong? Should it be phpwebsite setup/ask_install.php ???? Any help appreciated. Bob T. |
|
From: Matthew M. <ma...@tu...> - 2002-02-25 21:12:10
|
Hi all, Recently there have been disagreements among some developers. To foster cooperation and get the project's position in print, Brian and I decided to expand upon this and create a list of 'developer standards.' http://phpwebsite.appstate.edu/mod.php?mod=userpage&menu=1505&page_id=28 Brian and I want everyone to be little Fonzies, so please take a moment to read them over. Once again, if you haven't heard it recently, we truly appreciate everyone's effort and hard work. We just want this to be a fun project for all involved. Thanks, Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Alessandro P. (T. / J578) <al...@ti...> - 2002-02-25 15:03:09
|
On Mon, 2002-02-25 at 15:58, bo...@el... wrote: > It should never be because you would personally use a different > style. Every successful developer has a personal style. For > example, if you would prefer to use "echo" instead of "print", or > "||" instaed of "or", then do so, but don't try to change the work > of other people to suit your yourself. Again on this story ?!? I though we clarified it in the weekend.... uff... Alessandro -- Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087 phpWebSite Development Team http://phpwebsite.appstate.edu INWO Project coordinator http://inwoproject.sourceforge.net "I will carry you through, hicking and screaming, and in the end you will thank me" - Tyler Durden [from "Fight Club"] |
|
From: <bo...@el...> - 2002-02-25 14:54:13
|
Matt - I would like to put in my two cents on this issue. I don't know the complete background from your perspective, but I'd like you to consider these points: Open source is no different from other aspects of life where people have to work together in voluntary service. People need to respect each other, and tread gently on other peoples work. The best person to fix a bug is the programmer that created it. Control over code is not necessarily about posession. It should be about responsibilty. If I write something, and someone else changes it right away, then neither of us are really responsible for how it works after that. Both can walk away. Everyone will have their own preferences, and everyone needs to respect the work of others. If a developer changes someone elses code, it should be for a compelling reason. It should never be because you would personally use a different style. Every successful developer has a personal style. For example, if you would prefer to use "echo" instead of "print", or "||" instaed of "or", then do so, but don't try to change the work of other people to suit your yourself. Every programmer can learn to read a variety of styles, but no programmer can make the world conform to his/her own personal preferences. Bob Treumann On 25 Feb 2002 at 8:44, Matthew McNaney wrote: > Good day, > > As phpWebSite continues to grow and we add more developers, it is import= ant > to remind people of how CVS currently operates. > > First, if you commit something, it should work. If it doesn=92t work, th= en > someone might fix it. When you commit you are releasing it to the world.= If > you have a problem with someone repairing your code, don=92t commit. If = you > want to commit and still do not want people to touch your code, then mak= e > sure it has absolutely no bugs. I understand bugs can get by you, but I = am > weary of the possessiveness people have of their code. If you disagree w= ith > this, then you shouldn=92t be in Open Source. > > Second, if you are changing someone else=92s code, you should not change= the > functionality of the code without consulting the developer. Bug fixes ar= e > open season. > > Third, before you commit, update. Roll back is a bitch. > > If you have any problems or questions about these standards or anything = or > anyone else, contact Brian (br...@tu...) or myself directly. > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > ICQ: 141057403 > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Matthew M. <ma...@tu...> - 2002-02-25 13:58:01
|
As phpWebSite continues to grow and we add more developers, it is importa= nt to remind people of how CVS currently operates. First, if you commit something, it should work. If it doesn=92t work, the= n someone might fix it. When you commit you are releasing it to the world. = If you have a problem with someone repairing your code, don=92t commit. If y= ou want to commit and still do not want people to touch your code, then make sure it has absolutely no bugs. I understand bugs can get by you, but I a= m weary of the possessiveness people have of their code. If you disagree wi= th this, then you shouldn=92t be in Open Source. Second, if you are changing someone else=92s code, you should not change = the functionality of the code without consulting the developer. Bug fixes are open season. Third, before you commit, update. Roll back is a bitch. If you have any problems or questions about these standards or anything o= r anyone else, contact Brian or myself directly. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Matthew M. <ma...@tu...> - 2002-02-25 13:45:39
|
Good day, As phpWebSite continues to grow and we add more developers, it is importa= nt to remind people of how CVS currently operates. First, if you commit something, it should work. If it doesn=92t work, the= n someone might fix it. When you commit you are releasing it to the world. = If you have a problem with someone repairing your code, don=92t commit. If y= ou want to commit and still do not want people to touch your code, then make sure it has absolutely no bugs. I understand bugs can get by you, but I a= m weary of the possessiveness people have of their code. If you disagree wi= th this, then you shouldn=92t be in Open Source. Second, if you are changing someone else=92s code, you should not change = the functionality of the code without consulting the developer. Bug fixes are open season. Third, before you commit, update. Roll back is a bitch. If you have any problems or questions about these standards or anything o= r anyone else, contact Brian (br...@tu...) or myself directly. 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-02-25 03:39:20
|
I have set up the latest code, including the new weblinks and user created page stuff and anyone is welcome to sign in and test it. The host I use for these temporary development websites is cheap, but sometimes overwhelmed with traffic. If you get connection errors, it is NOT the fault of phpWebsite. Just keep trying if you see that problem. It is at: http://portal.dbserve.net/pws82 Report bugs, advise and suggestions to: Oopps ... sourceforge is down right now, so I can't give you the link. Anyway, report bugs and comments to the new CVS 8.x discussion group on sourceforge. If you can't get on there, just add your info as comments to the article "New Web Link Module Added to CVS" http://phpwebsite.appstate.edu/article.php?sid=218 Bob T. |
|
From: <bo...@el...> - 2002-02-24 19:21:17
|
I don't know where to report bugs. Sorry to alert the whole list. I did a fresh install on http://portal.dbserve.net/pws82 and got errors, one shown below. I added a print mysql_error statement to get the actual error. Table 'demo3.X2_mod_weblink_data' doesn't exist Warning: Supplied argument is not a valid MySQL result resource in /home/dbserve/www/pws82/admin.php on line 327 There are a number of bugs in the current CVS. I want to be able to test some code I have added, but there are so many unrelated bugs that I can't test my stuff. Hope the author(s) wil look, and fix them.... Also, I hope someone can tell me when the new version will be frozen, tested and released. |
|
From: Bob T. <bo...@el...> - 2002-02-21 18:15:57
|
On 21 Feb 2002 at 9:56, Matthew McNaney wrote: > >> Why does it matter if static information is served up when the > >> content is always written in one language anyway? > > > > Here are a few advantages: > > > > 1. Ability to log severity of error messages > > This sounds interesting. Please expand on this. I don't have my original psuedo code proposal in front of me, but in essence what I proposed is that each message is given a severity level. Then, based on a logging level, the fact that a certain message was given is recorded. In most programs, there are errors that should never occur. Programmers need to know it they do occur. For example, errors that say table does not exist, or unable to connect to database, or "What the F** happened", etc .. Also, if somene is doing something that may be a security risk, then they could be warned that their ip address and other information is being logged, just in case ... This would be like trying to execute scripts by coming at them from the wrong place for instance, or by guessing at parameters, or whatever ... > > > 2. Hardcoded statements with hard coded translations are hard to > > change. If you change one word in the program, for instance, to > > correct a spelling error, or clarify the message, then all the > > language files have to be changed. This means that mistakes in > > messages are less likely to be fixed. > > I agree. But I when programming I think it is much easier to type text > than rely on a code or function. And, if I am reading someone elses > code, it is easier to scan the TRANSLATE that find a code that points > to a line of text. What I would prefer is something that automates > tranlation. The "get_program_message() could also have a plain_text parameter. That way, messages could be displayed without having a code. The function could even log the messages it sees that don't have codes, so they could be fixed later. The message code could be added when the programming is done and stable. The original meaning of the message could be left as a comment. So if I am programming and I make a change in the file, I > can go to a module that is hooked to a database and make an edit. When > I make that edit, all language editors are notified. When they log in, > the most recent submissions and corrections are pointed out to them. > Then, right before we run the distro, the DATABASE of tranlations > makes the .pp files. I think this would not only help current > translations but also assist those who want to create a new language > file. > > > 3. If a site operator modifies the programs, you either have to > > modify the source program, then generate the language version, > > requiring an extra step, or, if you change the translated version > > and do a "diff" to the untranslated, your diff is so full of > > TRANSLATE differences that you can't find see your actual code > > changes. It would make program updates easier. > > If a site operator is modifying code, don't they already have a > tranlated version? If they are a developer, they should be working on > a CVS copy with the tranlates. Yes, if a developer plans on submitting code, they could always work on the untranslated version. But, translate takes too long, and I often make minor changes to my live site. I just back up a file, recode parts of it and go on. The problem comes when I try to identify what I have changed using diff against untranslated source. It is too hard. Rather than jump through all the hoops, people will just not submit code suggestions, or they won't be implemented because they can't just be dropped in place. > > 4 In the new core, I understand the goal is to have one tree support > > multiple sites. It wouldn't matter to me for my own uses, but in > > some uses, it would be necessary. In Quebec, Canada, for instance, > > I believe French and English are required by law for most public > > businesses. > > You can have one source support one language with multiple sites. But > this is still better in that you would only need one install per > language instead of one install per site. > > If you needed two different language sites you would still have to > write the content twice, on two different sites. The program obviously > doesn't translate content so even if the on-the-fly system was > running, it wouldn't do you any good. I think this is something that is only from your unique perspective. In Minneapolis/St Paul (Minnesota, USA), students in the public schools speak something like 66 different languages, from Hmong, Laotion, Chinese, Vietnamese, Swahili, Spanish, Somalian etc.... All of these people are multilingual. I don't think it is right to assume that all the content will be in one language. It could be in many. People want to navigate a site, and read instructions and warnings in their own language, even if they are able to read other languages, they are usually proficient in only one or two. And, as another poster said earlier, content could have a language indicator, so a visitor could search on things written in their own language. Translation interfaces can also be used, but you need to know what language your are dealing with to translate them. If phpWebsite is going to offer a solution that can be used in very diverse communities, I think that language support is not only a benefit, but is essential. > > > Well, personally I thought this would be a great benefit, but I > > won't push it. > > Well it is certainly nothing personal =) We just don't see the > benefit. > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > ICQ: 141057403 > > -- Bob Treumann, 651-603-1245 Elmwood Solutions Inc. (St. Paul, Minnesota) bo...@el... http://www.elmwood.com ORACLE Business Alliance Program Member |
|
From: Alessandro P. (T. / J578) <al...@ti...> - 2002-02-21 15:14:00
|
Finally I made it to work. I added a README.win32 into the dir make_distro/ of CVS version of phpWebSite. Following instructions listed into it you will be able to build localized CVS packages. Bye, Alessandro -- Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087 phpWebSite Development Team http://phpwebsite.appstate.edu INWO Project coordinator http://inwoproject.sourceforge.net "I will carry you through, hicking and screaming, and in the end you will thank me" - Tyler Durden [from "Fight Club"] |
5 messages has been excluded from this view by a project administrator.
