Foreign language behavior reverts back to English?

[Gerry Wiener]

When using Tibetan as a language with XTF we notice:

1. When collecting search results and pressing the Tibetan equivalent of Add, the English word Added appears on the screen but we would like Added to be replaced with the Tibetan word for Added. 

2. When looking at the book bag results we see a mixture of Tibetan and English for the words Author, Title, Published, Subjects and so on.

Is there a way to replace the English text with Tibetan in these cases?

Thank you very much,

Gerry Wiener

[dan haig]

Hi Gary,

First, are you using xtf-3? There are tentative steps towards i18n in there. 

At any rate, if you want interface terms (i.e. Add, Published and other utility terms the interface uses) to be in Tibetan, does that mean all the time, or only if the reader 'chooses' to have the interface terms in Tibetan? 

The solution to your problem depends on how you're going at this and what you're trying to make it do.

.d

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.
To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at http://groups.google.com/group/xtf-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Gerry Wiener]

Hi Dan,

We just upgraded to XTF 3.1. Ideally we would like to be able to switch between English and Tibetan interface terms using the language radio button. If that is difficult to accomplish, we can make the interface all Tibetan.

Thanks,

-g

[dan haig]

Ok, so it seems that you need to 'variabalize' all of the interface terms that you would like to see when the radio is toggled one way or the other. Have you not done this yet, or is this what seems to be failing? You mentioned the bookbag, is that the only context in which this fails?

.d

[Gerry Wiener]

Hi Dan,

In addition to establishing Tibetan as a radio button option in xrfCommon.xsl, we created a file called translation_tb.xml in the subdirectory g10n. This takes care of a good number of localization issues. The book bag area localization that we're having problems with is in resultFormatter.xsl located in the crossQuery directory subtree.  

The problem actually occurs when pressing the button to add a book to the Book Bag. Then the word Added appears and there is no Tibetan equivalent in translation_tb.xml to replace Added.

We're wondering whether we can extend the language translation to words like Added (and how to do this) or perhaps it's just easier to replace terms in resultFormatter.xsl (and other files) with Tibetan and not worry about the translation issue for now.

Thanks,

--Gerry

[dan haig]

> We're wondering whether we can extend the language translation to words like Added (and how to do this) or 

> perhaps it's just easier to replace terms in resultFormatter.xsl (and other files) with Tibetan and not worry about the 

> translation issue for now.

Well, the latter is certainly easier, but it rubs one the wrong way eh?

So. hm, happens just inside the bookbag:

         <xsl:when test="$smode = 'addToBag'">
            <span>Added</span>
         </xsl:when>

...and you've got an entry for it in your translation_tb file, but it's not reading it from the <transTable>? Why would the bookbag environment be any different? Something about being stored in session?

.d

[Gerry Wiener]

Yes, we also notice the same reversion to English behavior in Spanish and the other languages when adding to bookbag or pressing the Bookbag button.

-g

[dan haig]

Sounds like a bug for the good people at XTF to mull over.

[Oystein Reigem]

Hi,

Does the reversal to English last? I mean - what happens if you after bookbag use other functionality? Does the language then return to Spanish/Tibetan?

If so, could it simply be that the bookbag code hasn't got the necessary call-template's to do the translation?

                        <xsl:call-template name="translate">

                          <xsl:with-param name="resultTree">

                            ...

                          </xsl:with-param>

                        </xsl:call-template>

This was the case in my version. But my version is an old XTF 3. So when I try to help I'm not exactly on firm ground. :-)

(And I confess I don't actually use the bookbag functionality. But I noticed the call-template's were missing, and added them, before I decided not to use bookbag after all.)

Cheers,

- Øystein -

[gerry]

Hi Oystein,

It looks like you hit the nail on the head. We inserted the following mod in resultFormatter.xsl:

<xsl:when test="$smode = 'showBag'">

            <xsl:call-template name="translate">
               <xsl:with-param name="resultTree">

                  <xsl:apply-templates select="crossQueryResult" mode="results"/>
               </xsl:with-param>
            </xsl:call-template>
         </xsl:when>

That fixed the problem. It seems that there are other places in the same file having this problem.

Having little if any knowledge of xsl, it seems that this correction only applies to xsl:apply-templates lines.

Thanks for the follow-up.

--Gerry

[Oystein Reigem]

Hi,

The translate stuff applies to anything that is, or produces, elements. It can't translate plain text:

            <xsl:call-template name="translate">
               <xsl:with-param name="resultTree">

                  Some plain text
               </xsl:with-param>
            </xsl:call-template>

For this to work you'd have to put the text in an element:

            <xsl:call-template name="translate">
               <xsl:with-param name="resultTree">

                  <span>Some plain text</span>
               </xsl:with-param>
            </xsl:call-template>

Other caveats:

If you have two texts you want translated, and one of them is a substring of the other, the translation of the longer string might fail, with only the substring being translated. The order of the items in the translation_xy.xml files is important. Have the longer string before the shorter one.

Uh - now I said caveats in plural, but I suddenly became unsure of what applies to XTF and what applies to my changed version. I did some changes to the translation.

Cheers,

- Øystein -

[Gerry Wiener]

Hi Oystein,

Thanks for the follow-up. This is helpful for our ongoing work.

-Gerry

[Oystein Reigem]

Hi Gerry,

 

I said I had caveats, in plural. Here's one:

 

The method used for translation in XTF will have a problem if one and the same English term is used in two different places in the interface, but needs two different translations into the target language, say, Norwegian (my mother tongue). I met this problem once, but made a workaround. But to fix the problem properly I would have made the application able to translate not just into Norwegian, but English too. Say the English term "Close" needed two Norwegian translations "Lukk" and "Avslutt". Then I would have two source entries "Close" and "Close2", to be able to have two different Norwegian translations. But the translation file translation_en.xml for English could be tiny. It would just have to contain the single translation from "Close2" to "Close".

 

Another possibility would be to let the source terms all be codes instead of English terms, e.g, "T001", "T002", etc.

 

Pros:

 

You wouldn't have to worry about the wrong term being translated. They would never be substrings of each other.

 

The system would be more symmetric. This might appeal to some people.

 

Cons:

 

You would need English translations for all terms (codes). (But of course you wouldn't have to invent them from scratch.)

 

If the translation for some reason failed, the application interface would show codes only. Then it would be better with the default English and the odd funny "Close2".

 

Cheers,

 

- Øystein -