Disambiguation in translations

[Julio Camarero, modifié il y a 13 années.]

Hi everyone,

we have found several words in English that may have more than one meaning in other languages. For example, the word flag can be a noun or a verb in English, but we have different words for that in Spanish.

To solve this problem, we added (some time ago) the possibility to add a context to the key. So, for example, in Spanish we have:

flag=Estado
flag[action]=Marcar

If the portal finds the key "flag[action]" it will use "Marcar". If it finds "flag[xxx]" and that key doesn't exist, it will use the default flag.

There are more situations like these in other languages that we have been notified about and we are trying to fix, but I would thank everyone to let us know in this thread about more similar situations so that we can create those disambiguations in the Language.properties (it you can create an LPS it would be even better! )

For example, Milan told me he found this problem with the "Add" and "manage" links in the dockbar in Czech.

When propagated to other languages, by default they will be obtained from the default key, so that you don't have to worry about disambiguations if they don't exist in your language. For example, if now we need to add another flag[object] to Language.properties, in the Spanish translation it would be automatically translated as "Estado".

Thanks everyone!

[Milan Jaroš, modifié il y a 13 années.]

Hi, I'm so sorry I have missed this thread. But I remember discussion of this feature so I was looking forward...

I would like to find out solution for our problem. We have different meanings for blog entry and tag entry. There are at least three translations for entry etc. And it is not possible to fill in the universal one.

There are many keys that could be separated. E.g.:
no-entries-were-found => no-blog-entries-were-found & no-tag-entries-were-found ...
or
no-entries-were-found[tag] & no-entries-were-found[blog] ... e-mail, product, file, task, bookmark, asset, announcement
? What do you think ?


Another question is how can translator discover there is defined such string? Okay. Maybe this thread is right place. ;)

I'm sure we will use flag[action]. :o)


Regards

[Julio Camarero, modifié il y a 13 années.]

Hi Milan,

you would be able to find out about these searching for [] in your language file.

I wanted this thread to be the place where translators can ask liferay to add disambiguations to the code. For example, I didn't know that one about the entry, but I makes sense.

So, you would like to disambiguate:

entry[blog]
entry[bookmark]
entry[tag]
entry[asset]
entry
entry[product]
entry[file]
entry[task]
entry[announcement]

(and all the strings were the word entry appears)

isn't there a generic word for that in Czech (element, item...)? This one would be a hard work to do, but we can consider it anyway... maybe we could replace the strings using entry and just use the specific word for each element all around the portal. This one would be for 6.1 anyway, we are closing the release today.

cheers!

[Hitoshi Ozawa, modifié il y a 13 années.]

This may be a little different from what this topic is about, but I think every String on a page is mapped to a different key work in the properties file.
I think a simple word definition is insufficient. It would be better to know in which page the word is actually used so we can lookup the page.

For example, I found the word "state" translated to mean "condition" in Japanese. The actual usage was in the Control Panel address entry page to mean state as in "Illinois".

I think the quality of the translation would greatly improve if we are able to more easily know where the word exactly is used.

[Jonathon Omahen, modifié il y a 13 années.]

Ozawaさん,


As always, you seem to articulate issues that are at the forefront of many of our minds. Part of the problem of localisation/translation of the portal lies in how we deal with translation/localisation.

Strings are yes, placed individually in the properties file. However, unlike gettext solutions, the Strings are not automatically extracted from the source/runtime into the properties file. The programmer/developer is entirely responsible for referencing the properties keys in order to access a localised String versus a hard-coded String. That is the limitation of our current process.

The limits of localisation are really a part of the design of the portal at the moment. Since it was not originally structure to account for a lot of those cultural and linguistic differences, flexibility on those issues has to be engineered into the portal. Over the years, we have steadily progressed towards that point. At this stage, we really need a good, powerful translation tool and consolidated processes to deal with the translation process, tracking Strings/Keys that are currently being used, and allowing for flexible annotations.

I agree that greater flexibility is needed to be able to provide something along the lines of localisation containers/layouts, that can be specified for each region and language, depending on the needs of the area (things such as sign-up forms, name presentation, etc).

Thanks always for your great input.

[Hitoshi Ozawa, modifié il y a 13 années.]

There some good point about sorting the keys in the properties file, but is also makes it much harder to find association with the actual page where it is used.

The point I want to make is that what we really want is to have a page in end-users' local language which end-users can understand - this sometimes does not equate with getting a good technical translation. Good translation of a popular fiction book is those that entertains the reader - not the one that offers precise translations of words.

I'm asking other people to look at the translated version of Liferay portal to improve end-users' usability - not the quality of translation of words per se.

I think what we really need is a method to close the gap between the keys in the properties file and the actual page where they are used.

[Jonathon Omahen, modifié il y a 13 années.]

The point I was making about localisation is that there should be a flexible way to do things such as modify the layout of the default page, etc for each language to allow for that ability.

I understand that good translation means good context, which is part of the reasoning behind working in annotations. At the same time, like I mentioned in my other posts, a good tool that will show you the context it comes from would do much good in negating this issue.