[Phpwebsite-developers] Dynamic Translation (long)

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

A couple of developers have brought up dynamic language capabilities
in 0.9.4. Right now, we have no plans to support it on release. This
does not mean it never will, just not initially.

Here is our position. If you want to run a site in two or more
languages, you need to create a mirror site for each language. When
you create an announcement, page, block, etc. on one site, you will
need to log into the alternate site and enter it again in the new
language. Our program will handle the translation of the static
elements but you are responsible for the dynamic content.

Here is the position of others as I understand it. They do not want to
have separate sites. They want one site that translates not only the
static content, but the dynamic content as well. If a user logs into
the site, it should change both static and dynamic based on their
browser preferences.

I have problems with that.

Say the one site could do that. What of the comments? Three languages
on one site. Would it not be simpler to have a site dedicated to one
language so all those who comment can understand one another?

If your user interactivity is low (you gear your site less toward
community and more toward information) then this may not be an
issue. Let's look at some examples of how dynamic language could get
done.

The first example covers the process by which 0.9.3 worked. 0.9.3
created a table per dynamic language. The table contained the name of
the table it was emulating and the id of the content. When the dyn()
function was called, it would return the translated data in an column
array. If the data was not yet translated, it would return NULL.

Not a bad solution but it had some problems. One was that no one used
it. Granted, it lacked documentation however it was still difficult to
implement. Every time you wanted to display data, you would have to
check to see if the translation existed. If it didn't, you would grab
the original. We now have doubled the fetching process for every
query. The developer would also have to make sure that with each
insert and update, that the dynamic table knew about it.

The fact that few developers implemented this means, to me, that it
was hassle. We are trying to design 0.9.4 so that developers have to
learn less about the core. Using the 0.9.3 process was cumbersome.

This process, should it have been popular, would eventually made a
HUGE translation table. Imagine ONE table containing all the
translations for ten modules each having 1000 rows of data. Every time
a translation request was made, 10000 rows would need to be
searched. You can see why dynamic language capabilities were turned
off by default. It was slow.

Could this method be improved upon? Perhaps, but it would again depend
on the developer. They would have to query the language system each
time a change was made or each time content was read. 0.9.4 is written
so most of the time, you can save and load content via
objects. Dynamic language capability would remove that simplicity.

We do not repeat 0.9.3. table-per-language process in 0.9.4. The new
version uses po files for translation. You may ask, why not use them for
dynamic translation as well?

With static content, I know the data in the po file duplicates the data
in my code. With dynamic content, this file would have to be continually
updated. Every edit would create a new entry in the po file. If an entry
was deleted or updated, a search and replace on the text file would have
to be performed for that exact phrase. I can't imagine how this would
work much less writing the code for it.

Having a mirror site, in my opinion, solves all these problems. Sure I
have to enter the content more than once, but I would have to if I
were running extra languages off one site as well. I would enter it
once to create the original and then have to go to a separate
interface and translate it. I don't have to worry about my modules
complying with the dynamic standard. I don't have to worry about speed
because I am pulling data from only one database and not double
checking every entry. All comments are made in the native tongue of
the person viewing the site.

I have discussed this with other developers before. Many say it should
be done without offering the 'how'. Again, I'm not saying it will never
happen, I just can't think of a good way to do it. If you can come up
with a process that:

1) is simple for the developer to implement (or better yet, invisible),
2) does not create overhead with multiple processes,
3) can update content concurrently with the original, and
4) ultimately is easier than multiple sites

I am open to considering it. I don't think maintaining separate language
sites is easy, I just think that it is a simpler solution than the
alternatives.

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