Re: Requirements for updated site

Hi!

Dave Page wrote:
> 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.

>>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.

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?

>>Besides, can you give your opinion on sime other
>>usability-related layout changes I proposed?
>
> 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

>>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.

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

>>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!

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.