Re: Design for PHP Weather 2

[Martin G. <gim...@gi...>]

"Max Hammond" <ma...@fl...> writes:

> Hi all,
>=20
>> Should the pw_text object then include a file with the English
>> strings? If so, then how does the English translation override
>> something in pw_text?
>=20
> yes, include() it from the pw_text class. It wouldn't necessarily be
> an override, it could work in a similar way to the way it does at
> the moment.

But at the moment, we have subclasses for each language - this isn't
what you mean, is it?
=20
>> I know that I keep talking about this idea, but I have a feeling
>> that it'll come in handy at some time. We actually discussed using
>> it for the Hungarian translation where Mih=E1ly Gyulai had some
>> problems with some of the strings.
>=20
> There's nothing to stop us doing both... Most languages will work
> with the same "template", I think. We could make different classes
> for anything that's so different that our assumptions about syntax
> and grammar don't hold at all. I'm not keen to do things like this,
> but it's an option.

I agree that most languages should work with the same template. So
their classes would simply have a constructor that initializes
$strings with the right strings to fill in the template.

You would rather have this initialization of the $strings in a file
that's included by the template, right?
=20
> I'm still not convinced that subclassing the languages is going to
> help. I see it as "the purpose of the output object is to return
> text" - and that is true for whatever language, so it makes sense
> that that output object is configurable, rather than replacable.

I'm not talking about replacing the output module, I'm talking about
extending and overriding it for languages which dont fit into the
template provided by the basic output module.

>> This would enable an British-English class could inherit from the
>> current British-American class and change only a couple of words,
>> things like 'color' to 'colour' and so on. And if the
>> British-American class has overridden some methods in the
>> base-class (very unlikely) then that will benifit the
>> British-English class as well.
>=20
> You could override those same methods in the localisation include
> file, if you do:

But you can't override function definitions in an included file. That
is, unless we do something like this in our output module:

include("pw_locale_$language.inc");

if (!function_exists('output_temp')) {

  function output_temp($c, $f) { ... }

}

I'm not even sure that it would work as I've coded it above..

That's why I'm thinking about having the localisation subclass the
basic output instead of just including a file.
=20
> basic_text <------ pw_text
>                     ||
>                pw_loc_en-gb.inc
>=20
> Most of the functions we need are actually in the basic_text object,
> and pw_text only really exists to apply localisation to it.

Ahh - I think we almost agree :-) We have an basic_text object with
the methods needed to do textual output. (This is what locale_common
does today). Do you then want the pw_text object to subclass
basic_text or do you want basic_text to use an pw_text object like the
db_layer currently uses a db_mysql object?

Also, what is the difference between the basic_text and pw_text
classes? If pw_text only exists to apply localization, then why dont
we just call it pw_text_en, pw_text_da and so forth?

>> The first version of PHP Weather was written without any planning.
>=20
> And it's still a great piece of work - It does what it does very
> well.

Thanks - but the code that handles the databases are pretty ugly.
=20
=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather =3D> Shows the current weather on your webpage.
PHP Shell   =3D> A telnet-connection (almost :-) in a PHP page.