Re: [Phpwebsite-developers] Dynamic Translation (long)

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

On Thu, 2004-07-01 at 13:15, Ulf Hallmann wrote:
> would that mean that information-driven sites would have to stick on
> the current version and remain un-updatable for good?

No it doesn't, for reasons I will explain in a moment.

> Running different sites for each language is not an option for me, as
> it creates an admin overhead in most cases. Many sites are only
> partially translated (ony the most important "core" information)

If there was a dynamic system, this same problem could arise. Unless the
administrator translates the content, the site will have language gaps.
Compare the differences:

1) One site: admin enters the original content. admin then re-enters the
content for each language.

2) Multiple Sites: admin enters the original content on the hub. Admin
re-enters content on each language branch site.

Same amount of work.

>  - distributing different languages across different sites would
> result in incomplete content in some languages.

The same thing would happen with different languages on the same site.

>  Which leads to users getting confused.

Only users who would visit two different versions of the same site would
get confused, and that is not likely. Even were it likely, they would
surely understand, "oh they have translated this on my site yet."

>  Not to speak about having N systems to upgrade one a new version of
> the framwork gets release, to apply N patches, N sets of custom code
> and opening N times more potential security issues....

Branches don't work that way :) When you update the hub, all the
branches are updated as well. There will always be just ONE code base.
That is how we are able to update 30+ university sites at one time.

> For now, the current debate is IMHO more a political than a technical
> issue (as solutions exist which might not be optimal but which are
> sufficient for a lot of users).

I disagree. It IS a technical issue as I have to program it and feel
good about asking other developers and users to implement it. If I were
not concerned with usability, then 0.9.4 would 1) not have language
capabilities, 2) would not work in Windows, 3) would only work in MySQL.
In each of these cases however, I was able, through some effort, to
accommodate other versions.

>  My fear is, once you go ahead and apply the po technology, the lang
> module and some nice opportunities that come with it vanish.

I wrote the language module and I am writing the implementation of the
PO technology. It surprises me that people think I am changing this to
somehow make the program worse. If I thought updating the language
module was the way to go, I would do it. It isn't, and I'm not.

> I guess what I am trying to acomplish is to reduce the hassle you are
> talking about - for me some improvements in the lang mod and in the
> guidelines of it being supported by other mods would do the trick.

The only hassle, for me, would be maintaining the language module
instead of looking at new opportunities.

Run a Google search on PO files. Notice the amount of developers who
already use it. Creating something proprietary is more of a hassle than
using an accepted and embraced technology.

One last thing. I never said there wouldn't be tools to help you with
the language sites. I want to add a mirror option to the branch site
creation. That way you could post to the hub and it would disseminate
down to the other branches. The way we see it:

1) post on the hub
2) go to the branch
3) the content item is waiting approval for posting
4) edit the item into the other language and approve it

To me, this is an orderly, simple procedure.

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu