Content plugin translation issue

[Dalai]

2Usher
2white
2petermad
Thank you for your suggestions!

I guess that None here means that the are no line breaks in the file (only one line).

The plugin reads just a certain (configurable) number of bytes from each file by default. This could encompass the whole file but it doesn't have to.

Maybe you could use N/A instead of None, since detection of the line breaks is Not Applicable for that file.

Though the detection is limited to the number of bytes in the buffer (which doesn't need to be the whole file), this could work.

I thought about using "None detected" or "Not detected" but the thing is that each field choice can be shown in a custom columns view, so it should be as short as possible as well as precise. The term "None" fits perfectly...

On the other hand, the translation file can then be used to change the "N/A" to "None" again . This would only work when an external (English) language file is used in TC, but still.

Regards
Dalai

[AntonyD]

2Dalai

There is no plugin API version involved when dealing with plugin language files.

I know - that's why I said "it's time to improve the current translation logic"!
Older plugins won't be able to answer this question. And the new ones can. The ones that will start supporting this new capability.
You're trying to find some synonyms for your English terms. And what about translators who want to translate it into their language?
They may simply have no choice! That is, they will not be able to physically pick up something that fits the meaning, but differs in letters.
Therefore, it is proposed to introduce a new feature. And you don't have to introduce a new function - just the return value of some long-existing and important starter function that is triggered when the plugin is first connected, now it will be not just one number, but a sum of flags. And the old number is the first value of such a list of flags, and the new ones will mean new opportunities.

[petermad]

And what about translators who want to translate it into their language?
They may simply have no choice!

As far as I understand it: the translations can use the same words in two different multiple choice fields - as Dalai also points out here:

On the other hand, the translation file can then be used to change the "N/A" to "None" again

[AntonyD]

As far as I understand it

I can't say the same. IMHO taking into account the explanations provided by Mr.Ghisler - for translators
on another language it would be impossible in most cases to find "similar by logic, but different by letters" words...

[petermad]

for translators on another language it would be impossible in most cases to find "similar by logic, but different by letters" words..

Are you sure - I understand that the translators don't have any restrictions in what they can write - it is only the field names (to the left of the = ) that has to be unique.

[AntonyD]

Hmm, ok, let's wait the final version of plugin and test it.

[Usher]

I thought about using "None detected" or "Not detected"

What's wrong with "Not found", well known from HTTP 404 error message?

[Dalai]

I understand that the translators don't have any restrictions in what they can write - it is only the field names (to the left of the = ) that has to be unique.

Exactly.

What's wrong with "Not found", well known from HTTP 404 error message?

That doesn't fit "Some Type" very well, does it? Translators might even be tempted to translate that phrase directly so that it loses its original meaning. Now that I've changed the field name to "Line Breaks" one could argue that "Not found" fits a bit better, but I find "N/A" the most painless so far. If I were to change "BOM Type" to just "BOM" it would match the meaning better. But that doesn't remove the potential meaning-lost-in-translation thing.

Regards
Dalai

[Usher]

Then why not just use "EOL" (End Of Line) and "BOM"? They are acronyms commonly used in internet standards (RFC) and they don't need to be translated.
You can provide description and explanations for translators in readme.

[Dalai]

Then why not just use "EOL" (End Of Line) and "BOM"?

IMO, the current field choices fit just as good or bad to either - current or these suggested - field names.

They are acronyms commonly used in internet standards (RFC)

Do ordinary users know these abbreviations? How many users know what an internet standard or RFC is or have even read one?

[...] and they don't need to be translated.

I disagree. Technical people might often use these terms/abbreviations and don't need any translation, but I have my doubts that the same can be said about ordinary people.
However, it wouldn't be hard to translate EOL; there's even a word for end-of-line in German (Zeilenende). No idea about other languages though. Translating BOM is a different story and that's why I haven't translated it to German for now and just added "Byte Order Mark" as a kind of 'explanation' until I come up with something better (which is most likely never going to happen ).

You can provide description and explanations for translators in readme.

Well, it's probably a separate discussion where to put information for translators. In case of my WFX plugins it occurred more than once that a translator forgot to translate something despite there being a translation instructions file right next to the language files as well as in the plugin discussion thread on the forum...

Regards
Dalai

[petermad]

Translating BOM is a different story and that's why I haven't translated it to German for now and just added "Byte Order Mark"

In Danish Notepad, Microsoft uses the word STYKLISTE for BOM - stykliste means "parts list" or "list of items" - so it is such a bad translation - Microsoft's translator has obvoiusly mistaken BOM for Bill Of Materials instead of Byte Order Mark