nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Bilingual DCRs

zyggie04

Our client is generating templated content in two languages (french and english). Obviously, when entering/editing content in Teamsite's templating environment, the content editors rely on both languages fields being displayed on the same page.
This ends up in the result DCRs carrying both languages in language specific fields (such as en_text and fr_text).

The desired outcome is to have 4 EAs populated by Metatagger (Keywords_en, Keywords_fr, Description_en, Description_fr).

The tagging UI is setup properly (datacapture.cfg) but all attempts end up in both Keywords_ being populated with exact same keywords, although the "rack-script" specified in Keywords_ stipulates "-useLexicon Keywords_".
That's the only way I've found to differentiate the processing of the supplied DCR file, yet.

Is there any way - at all -to appropriately process bilingual DCRs?
Or should the whole Teamsite system be re-architected in order to comply to MT single language apparent limitation?

Many thanks,

Find more posts tagged with

Comments

Migrateduser

Not to worry. Here's the general approach:

1) Define two different content processors, one for english and one for french.

2) In the pre-processor step for each content processors, add a pre-processor that removes the other language content from the crackedText file. That will ensure that the models are only processing language-appropriate content.

3) Configure both content processors to be active for your file type and path regex. Both will run and the output will be merged into a single metadata record.

Also - be sure your keyword and summary models are appropriate to the language you are processing. Obviously, if there is an opportunity to build summarization/keyword indexes using your content (provided you have > 2000 assets), the results may be better than the out-of-the-box models.

zyggie04

would your suggested solution still be applicable if the inserted pre-processor acts upon the "original text" file instead?
If so, how would I insert my intervention on the "original text" and then forward the massaged result to the transconverter step?
If not, well, thanks for the answer anyways.

PS. I'm asking because removing the "other" language from the crackedText seems like a pretty tough job, actually emulating the kind of language deciphering software intelligence that MT is supposed to supply in the first place.

Migrateduser

You could provide a custom transconverter that only extracts certain fields.

BTW - here's the terminology that I'm using:

originalFile - what was submitted to MT
crackedText - plain text version of the content
metadataRecord - metadata extracted by MT

transconverters: originalFile -> crackedText + metadataRecord(native MD only)
preprocessors: original File + cracked Text + metadata Record -> modified cracked Text and/or metadataRecord
post/final-processorss: original File + cracked Text +metadata Record -> modified metadataRecord

Preprocessors are the easiest to use if you want to modify the crackedText prior to analysis by the different models (summarizer, recognizers, ...).

Cheers,
Clark

g_sal

I recommend that you do not put English and French content into one DCR. My associates and I have looked at 3 models, each with their advantages and disadvantages:

1. DCT per language, DCR per language, TPL per language
2. DCT with English and French fields, Bilingual DCR, TPL per language
3. DCT with Bilingual labels but one set of fields, DCR per language, TPL per DCT

Model 1 is intuitive but requires that you manage double the amount of assets for your content types. From experience, this is a bad idea because you will run into inconsistencies when updating and it requires a lot of effort to maintain.

Model 2 seems reasonable since the English and French pages are the same content. You've noticed already that MetaTagger becomes a problem. Even the search engine will have problems. The K2 engine reads a DCR to automatically determine its language. It will not mark a record both English and French, it will choose only one. Other problems are hypothetical, such as how will you divide language processes if the content is in the same file? What the implications through workflow, deployment, etc? What if your client requires an additional language?

Model 3 tries to avoid the pitfalls of 1 and 2. By using one DCT, and one TPL, you reduce the maintenance involved with duplicating your assets. The DCT will have bilingual labels, but the author will choose the language of the record and input content in language only. By producing language specifc DCRs, you avoid the metatagger and search problems. The model is also flexible to different business processes around authoring, approval, etc.

So far I've seen all three models implemented. I know with Model 2, however, that MetaTagger was not considered during the design phase, so they might have to go back to the drawing board. I've worked with Model 1 in the past and I'm avoiding it like the plague.

So while I can't say that Model 3 is unquestionably the way to go, I'm still putting my money down on separating the records.

Hope this helps

MMar_Ojuel

Hi g_sal,

It's been a while since you wrote this. We need to perform something similar to your model option 3, and I would like to know if finally you were able to generate 2 separate DCR from one DCT, and, in that case, what happens when someone tries to edit one of them.

I recommend that you do not put English and French content into one DCR. My associates and I have looked at 3 models, each with their advantages and disadvantages:

1. DCT per language, DCR per language, TPL per language
2. DCT with English and French fields, Bilingual DCR, TPL per language
3. DCT with Bilingual labels but one set of fields, DCR per language, TPL per DCT

Model 1 is intuitive but requires that you manage double the amount of assets for your content types. From experience, this is a bad idea because you will run into inconsistencies when updating and it requires a lot of effort to maintain.

Model 2 seems reasonable since the English and French pages are the same content. You've noticed already that MetaTagger becomes a problem. Even the search engine will have problems. The K2 engine reads a DCR to automatically determine its language. It will not mark a record both English and French, it will choose only one. Other problems are hypothetical, such as how will you divide language processes if the content is in the same file? What the implications through workflow, deployment, etc? What if your client requires an additional language?

Model 3 tries to avoid the pitfalls of 1 and 2. By using one DCT, and one TPL, you reduce the maintenance involved with duplicating your assets. The DCT will have bilingual labels, but the author will choose the language of the record and input content in language only. By producing language specifc DCRs, you avoid the metatagger and search problems. The model is also flexible to different business processes around authoring, approval, etc.

So far I've seen all three models implemented. I know with Model 2, however, that MetaTagger was not considered during the design phase, so they might have to go back to the drawing board. I've worked with Model 1 in the past and I'm avoiding it like the plague.

So while I can't say that Model 3 is unquestionably the way to go, I'm still putting my money down on separating the records.

Hope this helps

Cheers,