[haiku-commits] Re: r41046 - in haiku/trunk/data/catalogs: preferences/network servers/print
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: "haiku-commits@xxxxxxxxxxxxx" <haiku-commits@xxxxxxxxxxxxx>
- Date: Sun, 20 Mar 2011 14:55:22 +0100
> jonas@xxxxxxxxxxx wrote:
> > Log:
> > Catalog update for language ro.
>
> Is it really necessary to do that a) that often,
> and b) not in batches?
B) It's easier for a commit-aware user or langauge manager to
keep a watchful eye on commits if they're not one huge, jumbled
blob of 20+ languages. I don't think anyone else will care to look.
(At least my eyes glaze over pretty quickly.)
A) No, not this often. I've been testing a script which I hope can
automate some of the manual work or adapted for use on the server-side.
Anyhow, it's not desirable to commit from HTA in this way,
unsynchronized with the language managers work of approving strings,
since this can result in commits doing more harm than good.
An example:
- The 'de' language is 100% translated and approved.
- The 'de' manager asks for a commit on [haiku-i18n] and waits.
There is no guarantee when the commit will happen.
- The 'de' translators continue changing strings,
which the manager may not get to in time.
These are now unapproved and will result in removals from SVN.
- The committer gets the 'de' tarball and begins the commit process,
not knowing that the HTA state has changed since the 'de' lang
manager asked for the commit, not knowing that the tarball may
rip holes in the previously fully translated Haiku/de.
There are different ways to approach this.
1. Locking out translators from HTA from commit-request
to commit. Bad for productivity.
2. Instead of the committer downloading the tarball just in time
for the commit, the langauge manager gets it and attaches it to the
commit-request. Attachments would need to be allowed on [haiku-i18n]
or a new list made for this purpose. [haiku-i18n-commit-request] maybe.
3. A web service is made that lets each language manager commit
the current HTA state for his/her language. (With a cool-off
timeout of e.g. one week.) This would take some work, as catkey
files need to be testbuilt (and some of them patched or removed)
before getting committed.
Option 2 looks like the easiest to get going.
/Jonas
Other related posts:
