Once again, about MQL localisation
Lack of localisation contributes to the understanding of code by programmers who do not know your language. Therefore against.
Lack of localisation contributes to the understanding of code by programmers who do not know your language. Therefore against.
Things are much more interesting.
What prevents you from naming everything, including variables, with the same directive?
Then, using the wildcard we can easily get a basic English version.
And by extending the functionality of the directive, it is even possible to make support for selecting localizations from existing ones.
Lack of localisation contributes to the understanding of code by programmers who do not know your language. That's why I'm against it.
Yeah. And then, when people post the code, it will all be unlit,
and everyone will be naively asking:
- "Don't you know? You need to download an extra inline... vasya_localization_v2
And everyone will have different localization and with different versions.
What prevents you from naming everything, including variables, with the same directive?
Then, using the wildcard we can easily get the basic English version.
And by extending the functionality of the directive we can even make a support for choosing among the existing localizations.
Nothing else to do but translate the variable names! I'm going to program, not sit with dictionary to publish source.
I support, in 1C, for example, initially it was possible to program in Russian.
I'd kill you - honestly! I hate these "localisations".
There was a story on ithappens.ru just today:
#1497: Patriotic pornobabble
November 26, 2009, 09:00
rating: 628
At the end of 1980-th just had personal computers D3-28 (input from tape-recorder cassette), Electronica-60 (input from punched tape), DVK-2 (input from 5 "diskette with 360 Kb). And one of our departments bought 3 PCs "Iskra" (I do not remember modification number). All this took place in period of struggle of the party and people against foreign.
So these Iskra's had already had a BASIC in Russian. The translation was amazing. INPUT is "enter". Guess what END is? That's right, END.
That is how we nicknamed these "Sparks": "INPUT". However, they worked for us for about three months and then died (passed away?) Together with this porno-basic, we sent them to the manufacturing plant and they never came back to us.
For a long time I've been writing code in Cyrillic and never thought about the fact that reserved words need to be translated too (second nature habit).
Reading the code at once I see the meaning of "if", but when I write drafts and put "if" the meaning begins to get lost (second nature habit).
And then the reserved words do not have a direct meaning as understood by English speakers, so non-English speakers have the advantage of understanding that "if" is not an "if", "if" is an operator.
I'd kill you - honestly! I hate these localizations.
They'll get a discount in hell for that - for martyrdom! So it's only because of my humanity... :)
Urain писал(а) >>
Also, reserved words do not have a direct meaning as understood by English speakers, so non-English speakers have the advantage of understanding that "if" is not an "if", "if" is an operator.
English speakers don't have the advantage, they have the disadvantage. Because when I scroll through a program in my head, there is no "if", but the most abstract concept.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
The topic has already been touched upon in passing. I'm talking about the possibility to write experts completely in Russian (or any other language) in MQL. Something like this:
I know this feature is very useful. Who doubts or believes that it makes no sense (because any competent programmer should know English), I will answer just one objection: Why then the terminal has a bunch of language files of interface settings and why help is translated into different languages? ;)
As far as I understand the mechanism of a parser, it should have "lists" of strings of reserved words like for, long, ..... To fully "translate" the compiler to be able to compile texts in Russian, simply replace the text string "for" with "loop" etc. in the compiler's code and after that everything should work as before. List of correspondence of original English words and localized variants can be extracted from files, as now it is done for menu items of the terminal.
Here are possible pitfalls: in such a localized Russian text by the incluudom inserts system text with English words. You can avoid them only if the compiler recognizes both variants. That is, next to the table with English words must be placed another localized version of strings, so that the compiler can handle both "spellings".
There is a second possible pitfall: when you need to compile the text of the fragments in multiple languages. But they too can be solved. As a rule everything is localized into a single language which is used by the programmer. Therefore any mixture of languages can be first (probably with a separate tool or ME menu item) converted into English. And then all this sausage is converted into your mother tongue.
In the most extreme case, you can make another directive to the compiler #substitute source dest which will simply replace the string source with dest before compilation and compile the result. Then the localization can be done as suggested by TheXpert.
I know that the problem is solvable. I hope this improvement will not lead to radical rewriting of compiler code. I'm almost sure that developers will fight this idea with all their might and I understand their motives very well. But I have a faint hope that now while MQL5 is still in beta, this feature may be implemented, so I decided to raise this question once again: May it be possible to provide an opportunity to write programs in a mother tongue, in the language you are thinking of and in which you communicate with traders and customers?