[Kbabel] corrupted TM databases

[Nicolas Goutte]

On Monday 28 November 2005 11:25, Yury Tarasievich wrote:
> Glory, glory. Dumping and loading helped, with
> neglectable loss of content. Thanks to all concerned!
>
> There *was* something wrong with
> translations.<langcode>.db database, and attempt to
> dump it with no -r/-R parameter lead to infinitely
> growing output. However, -r helped.

It is nice to read that you could recovered most of the database.

>
> This experience, and related digging in the kbabel
> datadirs, uncovered some unpleasant inconsistencies in
> kbabel when dealing with TM (currently, in kbabel
> 3.4.3). These are:
>
> - 1. "rough translation" wants to open the <en-US> TM
> databases, disregarding the langcode defined in
> project;
>
> - "2. find [and replace]" wants to open the <en-US> TM
> databases, too, with additional BAD side-effect of
> everything changed (e.g., corrected!) landing in en-US
> (I remember wondering where did the en-US TM with
> translated content come from :)
>

> Both of these may or may not be helped by setting the
> langcode in the "default project" settings prior to
> executing the function, I didn't dig much.

Do you mean that the handling is ignoring the settings of the current project 
and only works with the settings of the default project?

>
> Also, I noticed Kbabel is constantly touching the TM
> .db's, even when not having written there actually. I
> do just a search (auto-search, actually) and all 4
> .db's modification times change?! This doesn't seem
> the sanest behaviour to me.

Perhaps the databases are not opened in a read-only mode. This might be 
needed, if it is not sure if writing will be needed or not.
(However I have not checked the code.)

>
> 3. Then, there's the issue of po's converted with
> translate toolkit (tranlate.sf.net). Kbabel insist on
> keys (so, msgid's) being unique, while it is not
> uncommon in, e.g., converted mozilla material, to see
> something like this (content is faked for the sake of
> example, the format is real):
>
> #: example1.label
> msgid "string A"
> msgstr "translation B"
>
> #: example2.label
> msgid "string A"
> msgstr "translation C"
>
> Then Kbabel doesn't want either to show the status of
> .po, or to save such file.

That is an invalid PO file, as it has duplicated entries.

If you want to save it from KBabel's editor, try the "special save" and 
disable the checking of the file.

Or you can change the project setting, not to check at save.

>
> I don't know how it should be solved correctly, per
> project setting of msg* commands, perhaps? Or adding
> the understanding of the "translate'd" .po syntax,
> possibly?
>

> Is something like this planned? I'm very keen to get
> this feature, I may even be willing to program it
> myself. I know C/C++ and Java -- do I have to know
> anything *specific* about Kbabel design etc.?

It would be nice if you could help, especially if you could compile on Qt3/
KDE3 and Qt4/KDE4. (Currently you cannot run KBabel on KDE4, but it should 
more or less compile.)

The Berkeley database is handled in KBabel by 
kdesdk/kbabel/kbabeldict/modules/dbsearchengine

>
> -cheers
(...)

Have a nice day!