AntonyD wrote: ↑2023-11-16, 09:41 UTCHOW to force this new plugin to use translated strings?
The plugin doesn't do any translation here, but TC does.
I've changed properly LANG file inside LineBreakInfo folder (installed plugins' destination)
and rebooted the Total - and... nothing.
The language TC uses for content plugin depends on the language used for TC. It's the same two or three letter code that's used for TC language files. For example, if you have set Russian language in TC, i.e. use wcmd_rus.lng, TC looks for a [rus] section in the plugin language file. For German it's wcmd_deu.lng and the section [deu], for Czech it's wcmd_cz.lng and section [cz] and so on.
Every string not found in that section is not translated and is let through 'unfiltered'. And if you use TC's internal English language, strings from content plugins won't be translated.
Tried to find inside the INI files some option to force the using of some LANG id - no luck...
As I said, TC does the translation
btw and what about:
NEL (U+0085): next line
LS (U+2028): line separator
PS (U+2029): paragraph separator
I'm aware of these, but they're Unicode only. For now I'm going to ignore them. I even wanted to ignore FF until I saw it being used in a GPL license file; that was easy to add.
And do you have an example of file with mixed Line Break types?
Sure. Search your %ProgramFiles% directory and you'll probably find quite a few. I've found them among installations of LibreOffice, VMware Workstation, Mozilla Thunderbird and PDFCreator. You can also create one yourself when appending a file with LFs to a file with CRs (or vice versa) via TC's copy and append feature.
By the way, how to distinguish when the file UTF-8 and it does not have a BOM marker from a file
that does not have this marker - because it is NOT even the UTF-8 file? Right now I see only NONE
for all cases. But definitely this is not a true logic. NONE should be used when the file IS indeed
the UTF-8. And when the file is NOT at all the UTF-8 coded - then it should be N/A imho.
The plugin just checks for the existence of a BOM, for UTF-8 it's the first three bytes (the first two bytes for UTF-16). It doesn't check the file's encoding (if there are any Unicode characters in the file) because that's irrelevant for counting line breaks and subsequently determining the line break type. Use a different plugin like
EncInfo if you want to know a file's encoding.
To moderators: This post and the previous one should probably be moved to the LineBreakInfo thread.
Regards
Dalai