Wednesday, 4 May 2011

Multiterm entries can't be edited?

I once had to cope with a strange behavior of Multiterm, after importing entries from another program. Let's take a look at these screenshots:

1. I have one entry, language is english, term is "Entry" and the field Source has been filled. Looks like a normal Multiterm entry

2. I want to edit this entry and I get this:

Surprise! My entry can't be edited. If I choose to cancel the editing, I just get the first screenshot again.

3. I enter "entry" in the english field and "entrée" in the french field and validate the change. I get this:

My entries are there, but now:
- there are 2 English flags
- the English term which was already there has been modified but is still in the "browse" pane
- the Source has disappeared

Let's take a look at the (Multiterm standard) colors of the terms: green is used for the source language, blue for the target language and black for the other language. The second "English" is not recognized as source language. In the first screenshot neither. Something is wrong with the language of the imported entry.

What happened?
This happened because the two "English" languages are not the same:
- the one which was defined for my termbase is "EN English". I prefer not to work with sublanguages in Multiterm because most entries are valid for all sublanguages and I don't want to duplicate them.
- and the language in my import file is "EN-GB English". Sometimes, I can't set another language code and sometimes, I don't check which one was used! In Multiterm Convert for instance, you can only choose between sublanguages...

The same "editing" problem happens if I import a file with languages (or even just fields) which are not defined for my termbase. You can view them, but you can't change them.

To get a clean termbase, you have 2 options: can change the definition of the termbase. Only new languages and fields can be added. If you want to change a language name or a field, you have to create a new termbase, adapt the old termbase definition and import again.

2. you can change the relevant fields in the xml before importing it in a new termbase, in our example "EN-GB" with "EN".

If you've imported "corrupted" data in an existing termbase (many good old entries and a few corrupted new entries), you have 2 possibilties:

1. you erase the new corrupted entries and import the modified xml again.

2. you export the whole database, change the corrupted data in the xml file (for instance "EN-GB" with "EN"), create a new termbank with the old definition and import everything.

Always think about which import option is the best for you: "default import" or "synchronize on entry".

No comments:

Post a Comment