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 |