Content plugin translation issue

[Dalai]

Hello into the community.

While working on a translation for one of my content plugins I stumbled across an issue that bothers me. Let's assume that a plugin returns two fields of type ft_MultipleChoice to TC. Let's further assume I want to translate these fields and their choices. The former is easy enough, but I have a problem with the latter. Here's the relevant part of the language file:

Code: Select all

[deu]
;--- Field X
None|SomeOption|SomeOtherOption=Keine|SomeOption|SomeOtherOption

;--- Field Y
None|Foo|Foobar|FooFoo|Blah=Kein|Foo|Foobar|FooFoo|Blah

The thing is that TC uses the translation "Keine" for both of these fields, but I want/need them to be different because the fields require a difference. Is there a way to achieve what I want?

Regards
Dalai

[Dalai]

Nobody want to comment on that? Would be good if Ghisler could explain why TC behaves like this, and maybe make a suggestion on how I could make this work.

Regards
Dalai

[ghisler(Author)]

Unfortunately string translation doesn't work like this:
1. Each line in a multiple choice field is translated separately
2. For each English string there can be only one translation
3. TC uses a translation cache. It works like this:
- TC reads all entries from a language-specific section, e.g. from [deu]
- it concatenates them all, separated by vertical lines, e.g. |string 1|string 2|string 3|string 4| (one for English and one for the translation)
- when translating a string, it searches for |string x| in English, looks at which position it stands, and then takes the translated string from the same position.

So the only way to get different translations would be to use different English words, e.g. instead of "none" use something longer like "no files" or "no data" or whatever is suitable in the situation.

[Dalai]

Thanks for the reponse and explanation!

So the only way to get different translations would be to use different English words, e.g. instead of "none" use something longer like "no files" or "no data" or whatever is suitable in the situation.

That's ... unfortunate. In this particular case the English 'template' contains the term "type" for both fields, and I don't know which other term would be suitable to have something other than "None"...

Regards
Dalai

[ghisler(Author)]

Use something like this:
no type
none (disabled)
none (no functionality)
etc.

[Dalai]

OK, seems like I need to make it even more specific. Which other terms would you use for "BOM Type" and "Line Break Type" so that the choices for these fields could be made different? Even if I would use just "BOM" and "Line Breaks" nothing would change for the translation. A choice like "No BOM" looks rather silly.

Regards
Dalai

[AntonyD]

It's strange that for something as important as translating strings for a plugin, the only suggestion was to "change the source text itself."
Dear Mr. Ghisler - maybe it’s worth doing something much more important - and correcting the very logic of the translation mechanism?
Which imho has been done very inappropriately at the moment. Too straightforwardly))))

[ghisler(Author)]

Sorry but most plugins are abandoned now, I can't just change the translation logic, that would break everything.

[AntonyD]

BUT definitely we can IMPROVE this logic! For plugins which can't for example return the supported version of Plugins API (this will cover all abandoned plugins) - you continue the work with outdated translation logic. For a modern/supported/new plugins - which WILL return the supported Plugins API version - you will imply the new - brand-new translation logic.
So for this Dalai will just add the proper answer for such a new API request from Total's side. And will properly prepare the new format of strings for translation.

[Dalai]

2AntonyD
There is no plugin API version involved when dealing with plugin language files. TC just uses any present .lng file with the same name as the plugin and tries to find a translation for each string in there. That's why one can add translations to any existing ancient/abandoned plugins, even if a plugin author never planned a translation.

The above description only applies to strings that are translated by TC itself, i.e. content plugins and the content plugin part of file-system plugins. Lister and packer plugins and the other part of file-system plugins are a different story; there TC doesn't do any translation and a plugin author needs to consider this from the start. But that doesn't involve any plugin API version either.

NB: A plugin doesn't return a plugin API version to TC but it's the other way around.

2all
Does anybody have a suggestion different terms/words for "Line Break Type" and/or "BOM Type" so that a choice "None" for either of them could be replaced with something longer?

Regards
Dalai

[white]

Does anybody have a suggestion different terms/words for "Line Break Type" and/or "BOM Type" so that a choice "None" for either of them could be replaced with something longer?

Perhaps simply include a string id number with each string?

Code: Select all

Line Break Type (#01)
None (#02)
None (#03)

[Dalai]

2white
My plugin provides two fields: "Line Break Type" and "BOM Type". Each of these fields has several choices. Maybe the following translation file excerpt is easier to understand:

Code: Select all

[eng]
;--- Line Break Type
Line Break Type=Line Break Type
None|Binary|LF|CR|CRLF|Mixed=None|Binary|LF (Line Feed)|CR (Carriage Return)|CRLF|Mixed

;--- BOM Type
BOM Type=BOM Type
None|UTF-8|UTF-16 LE|UTF-16 BE=None|UTF-8|UTF-16 Little Endian|UTF-16 Big Endian

To be able to provide different translations for the choice "None" I need to

• either change at least one of these choices from "None" to something else, but I have no idea which word would match the meaning of "None" as well as fit to either field name.
• or change at least one of the field names so that a simple "None" isn't one of the field's choices anymore.

Hopefully it's clear now what I want and where the problem lies. I thought about appending character(s), but that isn't something I'd like to do because it may confuse translators, especially when these characters are invisible (space or similar).

Regards
Dalai

[white]

2Dalai
When there are no line breaks, alternatives for None are:

Code: Select all

No Line Break
N/A
Not Applicable

When there are is no BOM, alternatives for None are:

Code: Select all

No BOM
No Byte Order Mark
BOMless

[petermad]

2Dalai

Line Break Type=Line Break Type
None|

I guess that None here means that the are no line beraks in the file (only one line). Maybe you could use N/A instead of None, since detection of the line breaks is Not Applicable for that file.

[Usher]

2Dalai
You can change one "None" to "Absent".