public inbox for [email protected]
help / color / mirror / Atom feedFrom: Magnus Hagander <[email protected]>
To: Adrian Maier <[email protected]>
Cc: PostgreSQL www <[email protected]>
Subject: Re: Multi-language to be or not to be
Date: Mon, 12 Feb 2007 23:04:52 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
> In particular, translating for the first time takes some time; the original
> files are updated in the meantime. It is getting painful when you
> realise that
> you are translating a moving target and you don't have any real tools for
> associating your translated file to the corresponding version of the
> original
> file. "cvs diff" is helpful but it's not enough
Not really that big a problem I think, unless you take a long time. Most
of our pages don't change often at all. The only stuff with a high
throughput is news and events, and they're just additions and not
modifications.
>> And yes, we've been talking abuot moving the pgweb stuff into svn
>> somewhere, but it's not done. And yes, if repo version numbers would
>> help a lot here, it might be a tipping factor.
>>
>> What I'm against is having to store the revision number manually in the
>> file, it seems like a very ugly and unmaintainable solution to me.
>
> It is ugly indeed, but i'm not sure what else can be done without requiring
> some work . A real solution would be having a table in the
> database with the status of the translations and a web interface for
> uploading
> the translations (so that the database would be updated ).
> But I can't expect anyone to work on this, particularly since noone
> ever provided
> any translation so far.
Right. Well, one option is to rip out what we have now in favor of
putting in something else - provided we do that in the end :-)
>> Well, once a page is out of date, I'd consider it "not translated". That
>> said, there needs to be a very clear policy and a way to deal with
>> it. Certain updates wouldn't need to invalidate the translatino (say a
>> spelling or grammar fix), whereas certain others will need it to be
>> completely invalidated right away (say information about a security
>> issue, where you really don't want out-of-date information in different
>> languages).
>
> Yes, a policy will be needed. But probably some translations need to
> show up before discussing about the policy.
>
> In 2-3 weeks from now i'll have some time to look at bringing up to date
> the files. But before spending time on them it would be nice to know
> whether the translation facility will be removed or not .. .
Well, it won't be removed if people like it and intend to use it. It
will be removed if nobody wants to use it. If will be removed if it's
bad and needs to be replaced with something better.
//Magnus
view thread (52+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Multi-language to be or not to be
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox