About translation

[ghost]

Hi trendschau, I noticed a small problem: version 1.4.0 received my translation regarding the options for the developer in settings (of course I just translate your English into my Italian). Version 1.4.0.1 having received Update for translations in dev area has translated my file in Italian into English ...

[trendschau]

Hi iusvar, sorry, I did not check the merge in detail, I see a lot of italian strings there, but also some english. Maybe hide-me used some old files so I have overwritten new translations with this merge? Then it might have happened to other languages, too.

If that is the problem, I am not sure how we can prevent this in future. I see some other projects work with crowdin, but not sure if that solves those problems. Or do you have another idea?

[ghost]

Hi trendschau,

my simple proposal is to work in "watertight compartments" that is everyone in their own sector of interest: obviously the "dominus" is you and you can decide on everything, as far as collaborations are concerned it would be better for everyone to be interested in their own design field.

Let me explain: I am interested in translation, both in the coding and in my language (the original English remains yours: in most cases (I make some changes just to shorten the keys) I move the labels from the code to the en.yaml file.

Hide-me should only be interested in its language (if he wants to add code, in my opinion, it would be better in php or javascript though: maybe a plugin). Besides, most programmers' editors have a function to sort lines: I swear I absolutely don't want to belittle the work and interests of others, but sorting just your own language takes less than five seconds.

What happened to the it.yaml file is not a restore to a previous version but a real English translation: when I write the Italian file, I don't do it in English, I write it directly in Italian. I have never posted an it.yaml written partly in English.

As for the formalism adopted by hide-me in the headings of language files, I am grateful to the Russian formalism de/en, in various fields of the human sciences it has given amazing results, I think for example of Propp. A certain degree of standardization is welcome, but it is better to stop before reaching uselessness and without contradicting oneself between form and content. I'll explain it in two points:

• referring the name of the language first in English and then in the language itself is, in my humble opinion, useless: the it.yaml file is for Italians and the term to indicate the Italian language is "Italiano", to the speakers of the others languages ​​shouldn't matter as you say "Italiano" in English.

• it is contradictory to add a second line with space for the author and then, do not respect the author, and change his text!

As for crowdin, I think it's just an extra job, I don't know if it's worth it, as it shouldn't solve the problem. I repeat, it is better that each speaker of a language is interested only in their own language. I am not against formalism, but I prefer to maximize profit, achieve the greatest profit with the least effort.

Finally, in the future, I too would have adopted the alphabetical order but only when the project had reached a good point: now I work for translation blocks precisely to benefit the authors of other languages! I'll explain this better too: I wanted to avoid other translators having to find every single untranslated key among all the others already translated.

This is what, I think and write in Italian, with sincerity and willingness to share, and then I translate into English, I hope that the English version does not appear too malicious (especially to hide-me). If so, I apologize in advance.

[trendschau]

Hi iusvar,

thank you, I got your point! And I totally agree that everybody should be fine with his own contributions to typemill, with his own domain of work and with the contributions of others.

As a first step I suggest that we commit the non-russian translation-files of version 1.4.0 to develop and master again to solve the actual problems.

In a second step I think we have to improve or change the review process for contributions somehow.

In my opinion, it is a valid step in an open source project to change the code of other developers or contributors and I am grateful if someone fixes or improves my own code with his contribution. Sometimes I also change code of contributions if I think that this code makes more sense (and I agree that my changes should be reviewed, too). So if we accept or reject contributions should be a point of ongoing discussions in my eyes.

I appologize that I did not review the changes in detail and that I did not start a discussion before merging. At the same time the translations are not my domain, so I think I should not start or lead discussions about contributions regarding translations. As you did introduce translations into typemill, do you think you can care about contributions regarding translations in the first place in future? If you agree, then I will simply wait for your reaction to those contributions in future or assign a review to you.

As a final step I think we could write down some rules or a contributors guide, because contributions should generally go into the develop branch and not into the master, and contributors should pull the latest develop branch before they make a pull request. I am not sure if it is possible to setup autotests with cypress on github somehow, so that we can run autotests before we merge contributions (just because there was some extra-time for bug-fixing in the past and for me it is difficult to find the time for it right now).

Let me know what you think about it, please!

[trendschau]

Hi iusvar,

I checked the changes again, from my understanding the script uses the english language-file as a template, checks all other language files and, if it does not find a string in that language file, then it adds the string from the english template with the english translation. For my german translations I think it is pretty useful because I can simply check my file and translate the english translations into german without comparing it manually with the english file.

But I don't want to decide that, we should discuss it with all contributors of translations.

Another idea is, that we add another line like #autosort: true and the python script only sorts the files that actively opt in. This way each translator can decide if he wants to use the script or not.

We also have to decide when to run that script.

Are any translations lost or are only some english strings added?

I would love to get a decision within the next week because I want to publish the next release soon.

Maybe @hide-me can join this discussion?

[hide-me]

Sorry guys for the late answer.

First of all, as I know I used the last version of lang files in dev area. And before my commit, lang files were changed at least more than a few days ago.

The next point is: you definitely right understand. My script just sorting strings and adding new strings from en file. If later you develop (for example) new settings for TypeMill you will just add N new strings with translation to en file and run the script. As a result: all files will have new strings for translation.

UPD. Yes, unfortunately, I lost a few translated into Italian strings, my bad. Idk maybe I lose them when I switched from master to dev area. I did a new small pull request with the fix. I'm sorry.

[hide-me]

referring the name of the language first in English and then in the language itself is, in my humble opinion, useless: the it.yaml file is for Italians and the term to indicate the Italian language is "Italiano", to the speakers of the others languages ​​shouldn't matter as you say "Italiano" in English.

Maybe you are right maybe not. We will see if TypeMill will be translated into more different languages. I adapt this idea from WordPress.

it is contradictory to add a second line with space for the author and then, do not respect the author, and change his text!

Hehehe, I did not change any translation except Russian. Just resorted to ordering strings in the dictionary. @iusvar just add yourself and don't be offended, headers with blank author line were added automatically. I didn’t aim to assign someone’s merits to myself, on the contrary, I want the translators to have the opportunity to "say about themselves".

And I don't think we need to use side service for translation, because we have only one file with a dictionary per language. Losing a few fresh strings in Italian - was my mistake, but it will not happen again, because all lang files already resorted and have some structure. So the script will just add new strings for translation from en.yaml

[trendschau]

thank you for you quick anwer!

What do you both think about an optin or optout for that script? Maybe an opt-out is even more useful so the standard behavior is that the script runs for each translation file, unless the file has an opt out?

This way everybody has the freedom to decide ... ?

[ghost]

I apologize for the delay, I have very little time.

For me it is okay to add a #autosort: true or false in the languages for the use of the script.

@hide-me, I'm not offended, I only have a short time to repeat a job, no problem :-) Thanks for the pull request recovery. (Just to laugh: Wordpress suffers from gigantism, it's a bad example for how to do a cms)

@trendschau, don't expect my reactions to other translations nor I can review other translations, sorry.

One last thing, I understood the importance of hide.me's script but I won't use it, I don't use / know python. Hide-me could do it, excluding my Italian, though :-)

Good job everyone

[hide-me]

For me it is okay to add a #autosort: true or false in the languages for the use of the script.

Yes, this is a good idea. I will add this feature soon. The point was if developers use my script after adding new strings, translators don't need to search, then export (copy-paste manually) new strings, not even need to open different files. Because translators can have a "very beginner level" of tech/IT knowledge. In the described scenario, translators do not need any skills except for the skill of translation/localization.

Again sorry for the bug which was in my pull request 😢

@trendschau Please check and merge my pull requests with the fix. Thank you for spending time with us to discuss this question!

[trendschau]

thank you, everything is up to date now with version 1.4.1