Subject: Re: Requirements for updated site

From: "Dave Page" <[email-masked]>
Date: Wed, 14 Jan 2004 21:57:19 -0000

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

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

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

> I only want to propose keeping English version in root, not 
> in en/: most of the mirror sites will be completely static 
> 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 need mod_rewrite to work properly.

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

No problem there, however let's be careful not over engineer things. If (for example) the entire site is in a single database then a single php file is all that is required. Splitting that file up too much into different layers 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 logical layers will help - I just want to avoid taking it to the Nth degree for the sake of it.

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

I haven't seen you post any.

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

That doesn't always work. Consider this text from the pgAdmin translation guidelines:
----
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 special care about including all %s and %d variable placeholders correctly. If you make a typo error, the application might crash. On some occasions, it might be necessary to reorder placeholders. In the following (fictive) example, both parameter positions are exchanged: 'Server %s user %s is logged in' could be translated by 'L\'utilisateur s%2$s est connecté au serveur %1$s.'. 
----

The word order (and possibly the appropriate tags around those words) changes in the translation, thus the translator must understand the markup to correctly rearrange it.

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

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

Regards, Dave.

---

From: Alexey Borzov <[email-masked]>
Date: Thu, 15 Jan 2004 12:31:30 +0300

Hi!

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

We won't. People will edit them locally and send for the inclusion in CVS.

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

I presume that 99.9% of these is documentation. And it won't be translated, at 
least not in *this* way.

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

Looking at the code: I presume they don't need it and can be completely static.

> No problem there, however let's be careful not over engineer things. If (for example) the entire site is in a single database then a single php file is all that is required. Splitting that file up…

Well, the fact that the whole site is dispatched by a single page does not mean 
that the whole code for the site should be in just one file. And it definitely 
does not mean that all the HTML should be in the same file.

> I realise it's more complex than that, and some abstraction of different logical layers will help - I just want to avoid taking it to the Nth degree for the sake of it.

Well, currently the person wanting to do some cosmetic changes to the design 
will have to wade through a ton of PHP code. I don't think a bit of abstraction 
will *hurt* here.

Right now I want to take up the following: port the current portal code to using 
the template engine. I will use HTML_Template_Sigma 
(http://pear.php.net/package/HTML_Template_Sigma) as this is the thing I'm most 
comfortable with and it has a simple enough template syntax.

I'll create a template for the common HTML "frame" and templates for all 
database-driven (as opposed to static) pages. I'll also split system/page.php 
into several files to ease further maintenance.

Is it OK?

> I haven't seen you post any.

Suggestions sent to pgsql-advocacy:
http://archives.postgresql.org/pgsql-advocacy/2004-01/msg00161.php
Mock-up:
http://oc.cs.msu.su/stuff/PostgreSQL.html

> The word order (and possibly the appropriate tags around those words) changes in the translation, thus the translator must understand the markup to correctly rearrange it.

If we choose between better design and lower barrier of entry for translators, I 
vote for design...

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

Now consider the number of people who are going to work on the site after the 
translations framework is in place...

We'll probably need a system to manage access to different content as well.