phpwebsite-developers

[Phpwebsite-developers] Language suggestion

[<dyn...@us...>]

Bob,

         Previously, the developers at Appstate mentioned that the reason 
they did not automate it in the script for others to control is because 
most people do not change their languages often.   It is a one time deal on 
average.

         The advantage is as you are thinking, but the disadvantage is that 
you would have to process that statement every time a user logs into the 
website.   This would slow down phpwebsite where it could be 
eliminated.   Of course this is all theoretical and maybe 
insignificant.    But I believe that was the logic for appstate to just 
translate it before it was downloaded.

         

Re: [Phpwebsite-developers] Language suggestion

[Bob T. <bo...@el...>]

Good points, but there may be good answers too.

Yes, it could be a bit slower, but since the entire site is database 
driven, how much difference would this really make?    If the 
calendar shows on every page, that is a pretty big hit on the 
database too.  Also the news blurbs in the right hand column.  All 
the pages are read from the database too.   Why would the language 
queries be special?

Also, there is a way to increase efficiency by storing frequently 
used phrases as session variables.

We would add one column to the language table to name the 
corresponding session variable.  Then instead of 
"show_program_message" we have "get_program_message", and return the 
value to the calling script.


Then, the language call would be:

if (!isset($sv_user_welcome)) 
   { $sv_user_welcome = get_program_message (mod=core,  
phrase='sv_user_welcome' )
 }

The session variable $sv_user_welcome is set inside 
get_program_message, and returned to the calling script.

This way, every individual language query is done once only per 
session.


On 20 Feb 2002 at 9:07, dyn...@us... wrote:

> Bob,
> 
>          Previously, the developers at Appstate mentioned that the
>          reason 
> they did not automate it in the script for others to control is
> because most people do not change their languages often.   It is a one
> time deal on average.
> 
>          The advantage is as you are thinking, but the disadvantage is
>          that 
> you would have to process that statement every time a user logs into
> the website.   This would slow down phpwebsite where it could be
> eliminated.   Of course this is all theoretical and maybe
> insignificant.    But I believe that was the logic for appstate to
> just translate it before it was downloaded.
> 
> 

--
Bob Treumann,  651-603-1245
Elmwood Solutions Inc. (St. Paul, Minnesota)
bo...@el...
http://www.elmwood.com
ORACLE Business Alliance Program Member

Re: [Phpwebsite-developers] Language suggestion

[Matthew M. <ma...@tu...>]

As stated before, we don't support this.

English version
<header>Welcome!</header>
<content>I entered all my content in English!</content>

French version
<header>Bienvenue!</header>
<content>I entered all my content in English!</content>

Italian
<header>Benvenuto!</header>
<content>I entered all my content in English!</content>

Why does it matter static information is served up when the content is
always written in one language anyway?

Even if it doesn't add delay, why create them if they are not needed?

Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493
ICQ: 141057403

Re: [Phpwebsite-developers] Language suggestion

[Bob T. <bo...@el...>]

On 20 Feb 2002 at 14:18, 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

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.

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.

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.     

Well, personally I thought this would be a great benefit, but  I 
won't push it.

Happy Coding!


  

--
Bob Treumann,  651-603-1245
Elmwood Solutions Inc. (St. Paul, Minnesota)
bo...@el...
http://www.elmwood.com
ORACLE Business Alliance Program Member

Re: [Phpwebsite-developers] Language suggestion

[Karsten D. <k.d...@fi...>]

Hi!

On Wed, Feb 20, 2002 at 01:59:43 -0600, Bob Treumann wrote:
> On 20 Feb 2002 at 14:18, 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:
[...]

The 4th point you mention seems to be a very strong point. Anyway,
here a few more thoughts on this, that came up in the past. And that
(partly) explain why it indeed _does_ matter to have the static stuff
served dynamically.

There was a thread started by Todd Owen on March 23rd 2001, the
subject was "Multi-lingual sites", that discusses some of the pros and
cons.

More recent is the thread started at the end of November 2001, where a
discussion about this emerged from "One among many" written by Matthew
McNaney. There Brian W. Brown lays out his thoughts in a message
titled "Re: the last crusade (is: Re: One among many)".

I have written a followup (Msg-ID: <200...@to...st>)
to this thread where I explain why switching languages on the fly is
(IMHO) needed even if we (yet) only have single-language content.

And Philip McAllister threw in some nice views about
internationalization/localisation from a professional point of view
which are worth a read.

> Well, personally I thought this would be a great benefit, but  I 
> won't push it.

Summing up: I am still supporting a dynamic language system. Even if
it means some impact on speed - we could wrap some caching around the
whole thing (see PEAR::Cache) to regain what we've lost.

Regards,
Karsten
-- 
fishfarm netsolutions - Karsten Dambekalns
Echternstr. 73 - 38100 Braunschweig

Tel. +49 531 1232902  mailto:k.d...@fi...
Fax. +49 531 1232906  http://www.fishfarm.de/
-----------------------------------------------------

Re: [Phpwebsite-developers] Language suggestion

[Bob T. <bo...@el...>]

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