farlang.templ.m4 to farlang.csv

[MKadaner]

What do you think about replacing farlang.templ.m4 with a CSV file? It could be something like this:

farlang.csv

,Language,,Russian,,English,,Czech,,German,,Hungarian,,Polish,,Spanish,,Slovak,,Italian,,Ukrainian,,Belarusian,,Lithuanian
,Language file,,FarRus.lng,,FarEng.lng,,FarCze.lng,,FarGer.lng,,FarHun.lng,,FarPol.lng,,FarSpa.lng,,FarSky.lng,,FarIta.lng,,FarUkr.lng,,FarBel.lng,,FarLit.lng
,Language description,,Russian (Русский),,English,,Czech (Čeština),,German (Deutsch),,Hungarian (Magyar),,Polish (Polski),,Spanish (Español),,Slovak (Slovenčina),,Italian (Italiano),,Ukrainian (Українська),,Belarusian (Беларуская),,Lithuanian (Lietuvių)
ID,Comment,U,,U,,U,,U,,U,,U,,U,,U,,U,,U,,U,,U,
MYes,,,Да,,Yes,,Ano,,Ja,,Igen,,Tak,,Si,,Áno,,&Si,,Так,,Так,,Taip
MNo,,,Нет,,No,,Ne,,Nein,,Nem,,Nie,,No,,Nie,,&No,,Ні,,Не,,Ne
MHelpF1,\nHelp KeyBar F1-12,,Помощь,,Help,,Nápověda,,Hilfe,,Súgó,,Pomoc,,Ayuda,,Pomocník,,Aiuto,,Допом,,Дапамога,U,Help

I'd like it very much. In fact, I'd like to have it before doing #600. I am a bit tired of counting lines inside label sections. People can edit this file with a proper tool. This is how it looks like

in Exell

in Google Sheets

I can effect the transformation and update the tools used to generate lang.inc and Far<Lng>.lng files.

[alabuzhev]

I'm not sure about CSV. Yes, counting lines can be annoying a bit, but is has been manageable so far.

Some cons I can think of:

• With all the languages in one line editing it without "proper tools" would be simply unfeasible.
• It would make diffs unreadable and PRs harder to review.
• We have hundreds of commas in the strings, so , probably won't do as the separator.

I'd prefer to keep the format and improve/extend the tools:

• It should be possible to make a tool to transform the templ into, say, xslx and back.
• It should be possible to write a script for Far Editor to highlight each language with a unique color.
• Etc.

[MKadaner]

With all the languages in one line editing it without "proper tools" would be simply unfeasible.

Matter of taste, of course. I think it should not be worse than now. In fact, I think it will be much better. Google Sheets is one of such "proper tools," and it is available for free for non-commercial use. BTW, please look how GitHub displays it!

@BestiaPL, you recently were one of the most active contributors to farlang.templ.m4. What do you think about "editability" of CSV vs. templ?

It would make diffs unreadable and PRs harder to review.

Could you please check out this example? Looks reasonable to me.

We have hundreds of commas in the strings, so , probably won't do as the separator.

CSV natively supports commas in strings. Such strings should be surrounded by double quotes (with double quotes doubled inside the string).

It should be possible to make a tool to transform the templ into, say, xslx and back.

Sure, it is possible. My point is that with CSV we do not need this back-and-forth transformation at all.

It should be possible to write a script for Far Editor to highlight each language with a unique color.

Oh, no! Isn't it enough of conventional "unconventional" rainbows all over the place?

[alabuzhev]

I think it should not be worse than now. In fact, I think it will be much better.

With F4?

Google Sheets is one of such "proper tools"

Google sheets is very nice, but you have to upload / download manually every time and it might share google code/google reader's fate one day, who knows.

BTW, please look how GitHub displays it!

It's nice indeed, but it's a viewer.

Could you please check out this example? Looks reasonable to me.

It does, but not all the strings are 2-3 characters long. See MSetFolderInfoNames or MCharacterIsNotSupportedByTheCodepage for example.

with CSV we do not need this back-and-forth transformation at all.

But we need a special editor to make editing comfortable.

I don't see a huge difference between "use external editor" and "use external editor with pre- & post-conversion".

[MKadaner]

If we are limited to the internal editor, the advantage may be less prominent indeed. Though I still hold that even in the internal editor CSV experience is on par or better than the tall flat list we have now. Two long lines out of 2200+ do not pose an insurmountable obstacle.

Can we at least add language markers?

#language file name, language name, language description
A:FarRus.lng Russian "Russian (Русский)"
B:FarEng.lng English "English"
C:FarCze.lng Czech "Czech (Čeština)"
D:FarGer.lng German "German (Deutsch)"
E:FarHun.lng Hungarian "Hungarian (Magyar)"
F:FarPol.lng Polish "Polish (Polski)"
G:FarSpa.lng Spanish "Spanish (Español)"
H:FarSky.lng Slovak "Slovak (Slovenčina)"
I:FarIta.lng Italian "Italian (Italiano)"
J:FarUkr.lng Ukrainian "Ukrainian (Українська)"
K:FarBel.lng Belarusian "Belarusian (Беларуская)"
L:FarLit.lng Lithuanian "Lithuanian (Lietuvių)"

. . .

MYes
`l://Version: 'FULLVERSION`
l:
A:"Да"
B:"Yes"
C:"Ano"
D:"Ja"
E:"Igen"
F:"Tak"
G:"Si"
H:"Áno"
I:"&Si"
J:"Так"
K:"Так"
L:"Taip"

MNo
A:"Нет"
B:"No"
C:"Ne"
D:"Nein"
E:"Nem"
F:"Nie"
G:"No"
H:"Nie"
I:"&No"
J:"Ні"
K:"Не"
L:"Ne"

[BestiaPL]

I apologize for only writing back now.
Editing the CSV file is not quite right, and neither is the Google/Excel spreadsheet - it's all about special characters (semicolon, comma) and quotation marks - these can be interpreted incorrectly.
This is not the worst idea - because you can hide unused columns with other languages. But with longer texts, the problem can be the lack of visibility of the entire text.

Currently, the best idea is @MKadaner idea - to give a tag with a language identifier at the beginning of the line. When translating new texts myself, I had to do a good job of counting which language in turn is Polish. If it was coded under some letter - it would be a great convenience.

[MKadaner]

I still see the language markers as a subpar workaround for a really ugly problem. Thugh, of course, it will be better than nothing.

Let me repeat. While I have limited experience with Google Sheets, I know for sure that MS Excel allows to transparently load and save well-formed CSV files, commas, quotes and all.

[alabuzhev]

Alternatively, do we actually need to keep all lngs in the same file, and not in 12 different files like

MYes="Yes"
MNo="No"
MOk="OK"
MHYes="&Yes"
MHNo="&No"
MHOk="&OK"
MCancel="Cancel"
...

?

Pros:

• no need to count lines
• translators can focus on a specific language

Cons:

• more files to edit when adding new strings
• files can go out of sync (but can be enforced with a build check, like hlfs).

[MKadaner]

Since I have no permissions to push to your repo, I transferred the branch to my repo and added one commit.

I started with retrofitting comments into lang.hpp. I think that lang.hpp should be used as the master list of all labels and comments for all language files. Please have a look. If everything is OK, I'll continue with the tool.

P.S. I also did some cleanup. Particularly, in lang.hpp, I replaced *BDRW with *BDRE in two places to match corresponding labels in the language files. Please confirm.

[alabuzhev]

Keeping comments in lang.hpp is a good idea.
I wrote a conversion script for *.lng.m4 and most of lang.hpp to simplify syncing with master.
I think running it incorporated all your changes, please confirm.

[MKadaner]

Thank you for the update. I did not flag spaces after // because, you know, preexisting code, etc. But of course, the formatting should be proper.

Looks like a few spaces are missing in the Slovak language file:

//Main CtrlShift
//Editor: Shift
//Editor: Alt
//Editor: Ctrl
//Editor: AltShift
//Editor: CtrlShift

Also, I would not insert apostrophe after "Far" in the Polish file. I do not know how it sounds in Polish and would trust the maintainer.

-MAskQuit="Czy chcesz wyjść z Fara"
+MAskQuit="Czy chcesz wyjść z Far'a"

I'll try to write the checking tool, at least the first version, during the coming long weekend.

P.S. I did not try you script (I do not have Python installed), just compared against the tip of your branch.

[alabuzhev]

a few spaces are missing in the Slovak language file

Are you sure?

Also, I would not insert apostrophe after "Far" in the Polish file. I do not know how it sounds in Polish and would trust the maintainer.

I did not insert it, it is there initially:

FarManager/far/farlang.templ.m4

Line 424 in ce7bbe1

"Czy chcesz wyjść z Far'a"

Apparently apostrophes got eaten by M4 in the final lngs because they were not escaped properly.
I'll double check all lngs (@BestiaPL no action needed for now I think).

[MKadaner]

I apologize for the mess. I looked at the diff (not at the actual files) and even then, apparently, looked upside down. :(

[BestiaPL]

Ok. I will change Polish translation of that string.

…

-- Andrzej Rudnik

On Oct 6, 2023 at 07:08, Michael Z. Kadaner ***@***.***> wrote: Thank you for the update. I did not flag spaces after // because, you know, preexisting code, etc. But of course, the formatting should be proper. Looks like a few spaces are missing in the Slovak language file: //Main CtrlShift //Editor: Shift //Editor: Alt //Editor: Ctrl //Editor: AltShift //Editor: CtrlShift Also, I would not insert apostrophe after "Far" in the Polish file. I do not know how it sounds in Polish and would trust the maintainer. -MAskQuit="Czy chcesz wyjść z Fara" +MAskQuit="Czy chcesz wyjść z Far'a" — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[MKadaner]

@alabuzhev, I created the first version of LngChecker: https://github.com/MKadaner/FarManager/tree/experimental/gh-630-split-farlang.templ.m4. Validation mode works (well, should work). Correction mode may have some rough edges.

My branch is stacked upon yours, the one with split language files. I am not sure how to proceed with the PR. Maybe you will just squash and merge everything?

[alabuzhev]

@MKadaner thank you, I'll try it.

Since the idea of this whole discussion is to make things easier, it would be nice to hear from people who actually edited these strings en masse.
@BestiaPL (and other translators, if you read this) - what do you think about the proposed format? Would it be easier to create and update?
I do see some minor downsides from a maintainer's point of view, but we can deal with them if that's the case.

[MKadaner]

@alabuzhev maybe we should move forward with this feature?

Tagging @BestiaPL again.