Re: Multi-language to be or not to be

Hi,

Dave Page wrote:
>> The main problem as "I told you back then" is that a person willing to
>> contribute to the website has to jump through a lot of hoops. As you
>> probably noticed, potential translators who participated in this thread
>> had no clue about the possibility of website translation. To know about
>> that requires either searching the archives of pgsql-www or looking at
>> pgweb module on gborg (which is itself "deprecated" for quite a bit of
>> time).
>
> Err, no it's not, though we don't tend to use the task manager any more.
> Or do you mean GBorg itself?

Yes, I meant GBorg itself, sorry for lack of clarity.

>> So to learn about translation infrastructure one essentially has to
>> already know about translation infrastructure.
>
> There are 'translation people' who know about the infrastructure who
> still have chosen not to work on translating the website - I suspect
> that part of the issue is simply the size of the task rather than
> difficultly in doing the job - the po files are there for the dynamic
> stuff, the admin site for the stuff that comes and goes on a regular
> basis, and the vast majority of the static pages never change (which
> means there is not necessarily any need for gettext type tools to
> monitor the changes).

I do understand the task is quite big, but attracting more people to it will
allow it to be split in more manageable chunks.

>> Well, even if you create a complete and standard infrastructure you'll
>> still need to translate at least
>> 1) Script messages and words from common templates. This can be done now
>> through complete and standard gettext.
>> 2) Content stored in database (news and such). There is an interface for
>> this now, though it may require polishing (no one can say for sure,
>> 'cause no one actually *used* that).
>>
>> The only real problem IMO is "static" pages containing a lot of text and
>> stored in CVS currently. It wasn't the brightest idea back then and they
>> probably belong in the database, alongside all other stuff.
>
> That would make management easier, but I don't think it will make a huge
> difference to translatability of the site - whilst you could check a
> page on the admin site periodically to check for changes since the last
> translation update, it would probably be easier to just monitor the
> pgweb-commit list and update translations reactively.

That will make a difference, as we gain 2 types of content to translate rather
than current 3. Also we can add customized notifications rather than make people
monitor the whole commits list.

Of course that leads us to implementing a means to add new pages and sections to
the website without having to manually add them to the navigation templates.
Then we need to have a flexible access rights infrastructure that will allow
translators to work on their stuff without the possibility that one day the
front page of postgresql.org will be presented in a mix of Japanese, Russian and
Turkish.

Also please note, I'm not trying to defend the current website architecture, it
definitely isn't the best one: my goal back then was to get the site out ASAP
and reuse as much previously written code as possible. But claiming that
translation "doesn't work" when no one ever tried to use it is laughable.