content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: Requirements for updated site
Date: Wed, 14 Jan 2004 21:57:19 -0000
Message-ID: <03AF4E498C591348A42FC93DEA9661B8720464@mail.vale-housing.co.uk>
Thread-Topic: [pgsql-www] Requirements for updated site
Thread-Index: AcPa4zdGLA0gms2oT2e2sDgZ6M7l1AAAxrPw
From: "Dave Page" <dpage@vale-housing.co.uk>
To: "Alexey Borzov" <borz_off@cs.msu.su>
Cc: <pgsql-www@postgresql.org>

=20

> -----Original Message-----
> From: Alexey Borzov [mailto:borz_off@cs.msu.su]=20
> Sent: 14 January 2004 21:13
> To: Dave Page
> Cc: pgsql-www@postgresql.org
> Subject: Re: [pgsql-www] Requirements for updated site
>=20
> Hi!
>=20
> Dave Page wrote:
> > 1) Should be multilingual for static and non-static pages.
>=20
> Looks like this part is working now. Although the l10n of the=20
> static (i.e. not kept in the DB) content can be made in a=20
> better way: using gettext or something similar. While the=20
> pages are mostly translated, the feedback messages in e.g.=20
> system/handleform.php are not.

Is it not easier to put everything in the DB? How would we handle the editt=
ing of po files on the server?

Bear in mind that the vast majority of the site (10K pages or so) is alread=
y in the database with embedded (and messy) HTML tags.

> I only want to propose keeping English version in root, not=20
> in en/: most of the mirror sites will be completely static=20
> and unable to redirect to en/ if the user hits the root.

Iirc (and bear in mind I don't know Andreas' code well), the mirrors only n=
eed mod_rewrite to work properly.

> > 3) XHTML/CSS compliant.
> > 4) The page width should be variable.
>=20
> The problem with the current code is that HTML is embedded in=20
> PHP. It is thus
> *extremely* difficult to edit it. Besides, files in=20
> system/layout contain not only presentation, but business=20
> logic as well (database queries, this kind of stuff).
>=20
> I suggest either
> a) Using a template engine
> or
> b) Creating HTML pages with *minimal* (presentation only) PHP=20
> embedded inside them.

No problem there, however let's be careful not over engineer things. If (fo=
r example) the entire site is in a single database then a single php file i=
s all that is required. Splitting that file up too much into different laye=
rs is unlikely to help with anything other than making it harder to see how=
 it works.

I realise it's more complex than that, and some abstraction of different lo=
gical layers will help - I just want to avoid taking it to the Nth degree f=
or the sake of it.

> Besides, can you give your opinion on sime other=20
> usability-related layout changes I proposed?

I haven't seen you post any.

> > 6) An interface must be implemented to allow easy translation of=20
> > pages, preferably without the need for the translators to know HTML.
>=20
> This can be done by using e.g. Wiki markup. But this will=20
> limit the layout possibilities.
>=20
> Although I don't see a big problem here: translators will not=20
> need to *write* HTML, but just to translate the words between tags.

That doesn't always work. Consider this text from the pgAdmin translation g=
uidelines:
----
Some messages include %s or %d variables placeholders. During execution, %s=
 will be replaced by a string and %d by a decimal number. Please take speci=
al care about including all %s and %d variable placeholders correctly. If y=
ou make a typo error, the application might crash. On some occasions, it mi=
ght be necessary to reorder placeholders. In the following (fictive) exampl=
e, both parameter positions are exchanged: 'Server %s user %s is logged in'=
 could be translated by 'L\'utilisateur s%2$s est connect=E9 au serveur %1$=
s.'.=20
----

The word order (and possibly the appropriate tags around those words) chang=
es in the translation, thus the translator must understand the markup to co=
rrectly rearrange it.

> I'd also add another entry:
> 7) Robust admin interface. The current one does not offer any=20
> protection from user errors.

No, it doesn't (but should). That's mainly because it's lifted from the cur=
rent code which is used almost entirely by Devrim, Robert & I - and we know=
 it's limitations!

Regards, Dave.