phpwebsite-developers

[Phpwebsite-developers] Re: the last crusade (is: Re: One among many)

[Brian W. B. <br...@tu...>]

> Ah, about the language system: yes, it may generally
> cause a performance slowdown... this
> could be considered by some people a right price to pay
> to have runtime per-user localization.

Obviously, the current language system could use some
improvement. I do, however, very much like a package-time
translation system. A few thoughts:

o A web-based, password protected, centralized language DB. A
translator could log in and see/translate the most recent
untranslated strings. This would also keep translators from
duplicating effort.

o System would continue to generate *.pp files for
package-time translation.

o Ship a "raw" version of phpWebSite. Running your own
translation is not hard...

o I have never understood the need for runtime translation (if
someone wants to explain, please do). What good is the ability
to display, say the text "Main Menu" in many different
languages when all of your content is locked-in to the
language in which it was written?

o Having our output be a simple string (i.e. there is no
"language engine" handling this output) allows for rather
simple customization. For example, if I really did not like
the term "Main Menu" it is easy for me to change this to read
"Navigation". While it is true that I would need to do this
each time I upgrade, it is a trival thing to do.

I welcome any and all thoughts on this. I would like to see
our methods for maintaining the language files improved, but I
remain unconviced as to the benefit of a runtime translation
system. To those who feel differently, please convince me!
phpWebSite is a team effort and I welcome debate and
discourse.

Kind Regards,
Brian Brown
phpWebSite Project Manager



-- 
Brian W. Brown
Director, Electronic Student Services
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608
vox: 828-262-7124
fax: 828-262-2585

L  I  N  U  X
     .~.
     /V\
    // \\
   /(   )\
    ^^-^^
Love the Penguin

Re: [Phpwebsite-developers] Re: the last crusade (is: Re: One among many)

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

On Fri, Nov 30, 2001 at 09:40:27AM -0500, Brian W. Brown wrote:
> > Ah, about the language system: yes, it may generally
> > cause a performance slowdown... this
> > could be considered by some people a right price to pay
> > to have runtime per-user localization.
> 
> Obviously, the current language system could use some
> improvement. I do, however, very much like a package-time
> translation system. A few thoughts:
[...]
> o I have never understood the need for runtime translation (if
> someone wants to explain, please do). What good is the ability
> to display, say the text "Main Menu" in many different
> languages when all of your content is locked-in to the
> language in which it was written?

I agree. This would in no way be of any help. But I would love to see
even that: multi language content. As soon as the "core language" can
be set during run time, it (would|should) be relatively easy to add a
"lang" field to e.g. the article database to distinguish between
different version of one article (one would have to connect those,
etc., but you get the point).

And voila - a multi language capable CMS. Which is not too useful for
a university setting (you might argue), unless you consider students
from foreign countries (who, again, should speak the language of their
university's country, ok :-).

But we were asked to set up phpWS for a school here in Germany, and
they want to have the thing multi-language (that might rule out phpWS,
although this would be sad) because this is a german-italian
school. Or think about international partnerships between whatever you
can imagine...

Thoughts?

Regards,
Karsten
-- 
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w³: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

[Phpwebsite-developers] Hello from Florida!

[Jason C. <cam...@xp...>]

Hey guys!  I haven't posted anything on here in a long time.  Thought I'd
just pop in and say hey!  I've been working on a few different projects,
one being Sinapze, a CMS system from scratch....anyways...

One thing I did see discussion about was on-the-fly language system.  I
currently have this type of system built into Sinapze.  Brian is right
about just having strings like "Main Menu" show up in a native language
could be possibly pointless.

The way I currently have it setup in Sinapze is with the module being one
class and the language file(s) being a class within the module's class,
based on the user's language that language file is the extension of the
module's class.  This makes the calls to the variables really easy $this-
>menutitle for example.  The language file(s) for the module are more or
less just glorified text files that just happen to be classes.

The way I have this setup for users, they can switch from language to
language on the fly from the user control panel or the admin can force the
users to all use the same language.  I think just having all the
actual "text" displaying stuff out of the actual module code is time saving
in itself and easier to maintain it that way.

Just my two cents on everything....keep up the good work guys!!

-- 
Jason Campbell
Soarion Technologies
www.soarion.com
www.sinapze.com

Re: [Phpwebsite-developers] Re: the last crusade (is: Re: One among many)

[Philip M. <lis...@li...>]

I hope you don't mind me throwing my 2p in here, but the subject of
localisation is one that has been a major part of my career for the last 2
years.

This mail is not intended to sway you one way or the other, but I guess,
just to reassure you that any localisation effort runs into exactly the same
problems and other people have "been there before" :-)

As you no doubt know by now, localisation is never an easy task and there is
never one 'catch all' solution that caters for all situations, most often it
is a matter or compromise.

As a quick background on my experience in localisation:

I work for a B2B ASP providing ticketing software in 8 different languages
to a global audience.

The previous version of our software used a build-time translation system
only. The current version uses run-time translation combined with
user-configured, multilingual text.

The software provides the facility to change the language of the front-end
at any time during the purchase process.


Obviously, localisation incorporates more than just translations and we
regularly have to deal with different timezones and currency issues. I skim
over these as I don't think them relevant to phpWS.

The number of distinct phrases within our application is now within the
order of tens of thousands This affected our choice of how to deal with
translation.

We use a combination of translation agencies and in-house translation staff
to deal with translating the phrases, and the phrases are provided in the
form of a CSV file of the format:

placeholder,language_code,Phrase to translate,Context of the phrase.

'placeholder' is our system code for the text, and our pages have
translatable placeholders in them rather than English. Not so far removed
from phpWS, and pretty much the standard way of localising a product :-)

'language_code' is the language the phrase is in, be it en_GB es_ES, nl_NL,
pt_PR etc.

'Phrase to translate' is pretty self-explanatory.

'Context of the phrase' is important to translators as it gives them an
indication of the use of a phrase within the system.

e.g. The phrase 'Your account' comes with an attached context of 'This text
is a link. The user can click on this link to access their previous purchase
history, billing details and contact details.' It just helps to pin the
phrase down for accurate translation :-)

This allows us to:

* Split out translations for each language code
* Retain the placeholder -> phrase mapping
* Give the translator both the phrase to translate and the context of that
phrase.

We did toy around with other ideas for translation systems, but these were
ditched due to time constraints.

The best all-round idea that we came up with was to create a new user-level
for a translator.

This translator user would be shown the same interface as a normal user, but
as well as having the text in the right places in the interface, would be
presented with text boxes (alongside or below the translatable text) to
allow them to translate the phrase directly on the page, thus allowing the
translator to view the context of that phrase in-situ.

This is, however, not an easy feat. The best compromise is to try and give a
context for the phrase so that it can be accurately translated. :-)

IMHO, I agree with Brian that a build-time translation system is much more
suited to the needs of phpWS since there is no perceived need to change
languages on the fly.

However, I would also like to see a system where the admin could change the
wording of phrases within the user-facing portion of phpWS. I.e. the ability
to change the wording of 'Main Menu' or the 'sign up now' wording to suit
their needs, without having to hack the code directly. This could be done
with an include file...

There is no reason why this has to be run-time either. There is nothing to
stop someone setting up an online phpWS translation tool where any user can
alter the phrasing of a base language file to suit their needs, and then
download the result to plug into their system.

Finally, the result of spending 1/4 of my work time for the last 2 years on
product localisation has taught me that there are only 2 ways to release
apps in multi-lingual form:

1) Release the default language ahead of the others and then release the
translated versions when the translations are in.

2) Create a code-freeze deadline and have the phrases translated while the
software is in the testing phase, then release all languages simultaneously.

Case 1 allows development to continue regardless of the state of other
localised releases, while case 2 ties the development schedule into
translation deadlines but results in a better overall product.

I sincerely hope I didn't sound as if I was on a high horse here, and it was
not my intention to step on anyone's toes. I just thought you might like
some reassurance that localisation is a common and ongoing problem. With the
Web being global, respect is rightfully deserved by those that realise this
and work towards global solutions :-)

Regards, Phil
--
Philip McAllister
ph...@li...
"All I ask is the chance to prove that money can't make me happy." - Spike
Milligan