support fon non-latin languages / Unterstützung für nicht-Latein-Sprachen

[evaki]

>>...möglicherweise in der Anmeldeform usw. ...
So kann's gehen, also nicht nur mir.
"Unicode im Login" wäre möglicherweise eher haften geblieben.

Falls ich es noch immer nicht verstanden haben mag, bitte ich um Geduld.
Die Verwendung von Unicode in Login, Formularen usw. wäre mehr als sinnvoll.
Das erlebe ich bei unseren Anwendern, die zwar international unterwegs sind (erwähnte ja auch schon das chinesische Porzellan bei einem Anwender), "ihre" entsprechend konfigurierten PC's etc. nutzen, aber bei einem CMS keines ihrer Schriftzeichen nutzen können, wo aber ansonsten alle "Innereien" sprachspezifisch ausgelegt sind.

>>Antwort in Kurzforn: Nein
WB-BE:"Es wurden ungültige Zeichen für den Loginnamen verwendet"

Die Verwendung von Unicode würde zudem das "Erraten" von Daten allein wg. des Zeichenumfangs noch weiter erschweren - wie z.B. bei Chinesisch. Kann ja wer schon üben, die Seidenstraße führt auch bald zu Deiner Tür.
Jo, bei Oma war's der Russe, bald is'es der Chinese...

[Gast]

die Frage war eigentlich einfach gehalten: Ist es möglich, das beim Login/Registrierung die Eingabe in der Sprache des Benutzers erfolgen kann?

Antwort in Kurzforn: Nein

Das ist keine Kritik und keine Aufforderung, etwas zu unternehmen. Es war reine Information. Hätte jemand gesagt, das funktioniert seit Jahren bei mir, hätte ich eine Bildungslücke, die es zu schließen gilt.

es geht nicht um mögliche Veränderungen in der Zukunft oder Hacks im aktuellem System und auch nicht um das Eingeben von Inhalten. Im speziellem Fall geht es um Frontend-User, die Inhalte nur nach vorheriger Anmeldung lesen dürfen. Es ist einem User in der Praxis nicht zumutbar, zum Durchführen eines Logins erst einen IT-Lehrgang zu besuchen. Entweder kennt er das benötigte Verfahren (use latin-characters) oder er wird sich eine andere Informationsquelle suchen.
Das eine Webseite (wie eine meiner Seiten) ein wirkliches Alleinstellungsmerkmal besitzt, ist doch heute eher selten und dementsprechend ist die Schwelle "was kann ich als Betreiber einem Besucher zumuten" auch recht niedrig.
Das Problem als solches (Login nur mit ASCII-0-9) ist ja in der Praxis überall vorhanden, WP arbeitet da mit nachinstallierbaren Plugins. Eine für mich persönlich durchaus interessante Lösung, einen Core "aufzupeppen", würde aber erst einmal grundsätzliche Schnittstellen benötigen.
Eine andere, recht simple nutzt Bakery seit Jahren. Ich glaub, in 2015 hatte ich das mit Christoph "entwickelt". Basis aller Validationen im Käufer-Adress-Formular ist Latin. Über die verwendeten Sprachdateien werden die entsprechenden Parameter übergeben, eben Cyrillic, Hebrew, Greek usw, dieser Parameter läuft dann über einen Switch und wird dann der Validation dynamisch hinzugefügt. Das hatte so zumindest damals funktioniert. 

google translation
The question was actually kept simple: Is it possible that when logging in / registration the input in the language of the user can be?

Answer in short form: No

This is not a criticism or an invitation to do something. It was pure information. If someone had said that works for years with me, I would have an educational gap, which must be closed.

it's not about possible changes in the future or hacks in the current system, nor about inputting content. In the special case, it is about front-end users who are allowed to read content only after prior registration. It is unreasonable for a user in practice to attend an IT course to complete a login. Either he knows the needed procedure (use latin-characters) or he will look for another source of information.
The one website (like one of my pages) has a real unique selling proposition, but today is rather rare and accordingly, the threshold "what can I expect as operator from the visitor" is also quite low.
The problem as such (login only with ASCII-0-9) is indeed everywhere in practice, WP works there with nachinstallierbaren plugins. For me personally a very interesting solution to "spice up" a core would first of all require basic interfaces.
Another, quite simple Bakery has been using for years. I think in 2015 I had "developed" that with Christoph. The basis of all validations in the buyer address form is Latin. From the language files come's a parameter namely Cyrillic, Hebrew, Greek, etc. This parameter then runs through a switch and is then dynamically added to the validation. That had worked that way at least then.

@crnogorac081: do you have (frontend) users in your projects and, if YES, login / displayname in they own language?

[crnogorac081]

Im not saying this is simple task, it is dificuilt and there must be afterwork for each native language

Im saying just for his case if you type Aleksandr (cyrilic) that code translate this to utf8 latin Alexander / or whatever / and save it as is to database, so there is unique login name.

[evaki]

copy&paste in das Terminalfenster übertragen

Genau so machen's "meine" Anwender, bei längeren Texten ebenso.
Wichtig ist's u.a. 'nen gescheiten Editor zu haben, und eine ebenso gescheite Schnittstelle im CMS.
(Aus Verlagssystemen heraus geht's ohne Geschwurbel)
MfG. Evaki
ps. Ich eperimentiere immer noch für einen Anwender chinesisches Porzellan in CMS und Filesystem zu integrieren. Der Hoster ist schon aufgeschreckt, da jetzt an einigen Orten ein wenig Unerwünschtes auftritt. Betrifft aber nur das Verwaltungssystem, nicht den eigentlichen Server. Es geht also.

[DarkViper]

Rein theoretisch (habs nicht getestet) sollte das funktionieren seit konsequent utf-8 benutzt wird, egal ob kyrillisch, chinesisch oder bayrisch. Eventuell müssen verschiedene Validierungen geändert werden (ist aber, wie Dietmar schon sagte, ein Fall für nach der 2.12.2).

Die Eingabe von Wörtern aus dem lateinischen Alphabet auf einer kyrillischen Tastatur (oder umgekehrt) kann schon mal zur Sträflingsarbeit ausarten. Die Buchstaben/Zeichen aus den einzelnen Alphabeten sind schlicht nicht 1:1 einander zuordenbar. Mit normalem Übersetzen hat das nichts zu tun.

Da irgendeine Softwarelösung zu basteln dürfte ein vergebliches Unterfangen sein, da man letztendlich nicht nur kyrillisch sondern auch türkisch, französisch, tschechisch, japanisch, thai und viele viele andere Alphabete berücksichtigen müsste. In UTF-8 sind das etliche zehntausend unterschiedliche Zeichen.
Sprachvariablen werden erst zu einem 'Problem', wenn die Texte in mehreren Sprachen geschrieben werden sollen. Die Schlüsselwörter sind eh alle englisch, also ASCII 0-9 und a-z, was eigentlich auf jeder Tastatur/jedem Rechner verfügbar sein sollte. Nur die einzelnen Sprachen....

Eine 'einfache' Transliteration ist definitiv auch keine Lösung wie das Beispiel mit dem 'Alexander' zeigt

Code Select Expand


// kyrillisch     // übersetzt     // transliteriert
Александр         Alexander        Aleksandr

Die Übersetzung funktioniert, hat aber wie jede Übersetzung ein Problem speziell mit Eigennamen etc.
Bei der Transliteration werden die Kyrillischen Zeichen eher nach ihrem Klang zugeordnet, was nicht zwingend der echten Buchstabenfolge entspricht.
Folglich kann man sich bei beiden Möglichkeiten nicht auf eine korrekte Eingabe verlassen. Was speziell bei Loginnamen und Passwörtern fatal sein kann.

Vor ein paar Jahren stand ich vor genau diesem Problem, als ich aus einem Internetcafe in Istanbul remote auf einen meiner Server zugreifen musste. Ich konnte mit der türkischen Tastatur einfach nicht alle Zeichen eingeben, die ich benötigte.
Da erinnerte ich mich daran, dass es in Windows ein kleines Programm gab, um alle möglichen Sonderzeichen einzugeben. Hier konnte ich per Maus meine deutsch/englischen Texte schreiben und per copy&paste in das Terminalfenster übertragen..  et voilà .. ich konnte den Server reparieren.

--- google translate ----------------

Purely theoretically (not tested) that should work since utf-8 is consistently used, whether Cyrillic, Chinese or Bavarian. It may be necessary to change various validations (but, as Dietmar said, this is a case for according of 2.12.2).

Entering words from the Latin alphabet on a Cyrillic keyboard (or vice versa) can sometimes degenerate into convict work. The letters / characters from the individual alphabets are simply not one-to-one. This has nothing to do with normal translation.

Since any software solution to tinkering might be a fruitless undertaking, since one would have to consider not only Cyrillic but also Turkish, French, Czech, Japanese, Thai and many other alphabets. In UTF-8, these are tens of thousands of different characters.
Language variables only become a 'problem' when the texts are to be written in multiple languages. The keywords are all English, ie ASCII 0-9 and a-z, which should be available on every keyboard / machine. Only the individual languages ​​....: |

A 'simple' transliteration is definitely not a solution as the example with the 'Alexander' shows

Code Select Expand


// kyrillisch     // übersetzt     // transliteriert
Александр         Alexander        Aleksandr

The translation works, but like any translation has a problem specifically with proper names etc.
In the case of transliteration, the Cyrillic characters are assigned according to their sound, which does not necessarily correspond to the true letter sequence.
Consequently, one can not rely on a correct input for both options. What can be fatal especially with login names and passwords.

A few years ago, I faced this problem when I had to remotely access one of my servers from an Internet cafe in Istanbul. I simply could not enter all the characters I needed with the Turkish keyboard.
Then I remembered that there was a small program in Windows to enter all sorts of special characters. Here I was able to write my German / English texts by mouse and copy & paste in the terminal window transferred .. et voila .. I was able to repair the server.

[Luisehahne]

I know, there is a lot of work after WB 2.12.2. It's not so easy with a code which is 14 years old.

Dietmar

[crnogorac081]

For login:
First detect cyrilic
https://stackoverflow.com/questions/3212266/detecting-russian-characters-on-a-form-in-php
Then translate
https://stackoverflow.com/questions/7461406/cyrillic-transliteration-in-php

[Gast]

a question in my emails and not possible for me, to give a answer....

in this special case, the question come's from bulgaria. i'm sure, it's not possible for every bulgarian, to change the keyboard layout to latin letters
translate language variabels + files is not the problem, but is it possible, that a bulgarian user use cyrillic letters , maybe in the login form etc. for example: Александр instead of (latin letters) Alexander
the project use also frontend signup, so i think also for this process

german translation
eine frage in meinen emails und ist es mir nicht möglich, eine antwort zu geben ....

In diesem speziellen Fall kommt die Frage aus Bulgarien. Ich bin mir sicher, dass es nicht jedem Bulgaren möglich ist, die Tastaturbelegung in lateinische Buchstaben zu ändern
Das Übersetzen von Sprachvariablen + Dateien ist nicht das Problem, aber es ist möglich, dass ein bulgarischer Benutzer kyrillische Buchstaben verwendet, möglicherweise in der Anmeldeform usw. Zum Beispiel: Александр anstelle von (lateinischen Buchstaben) Alexander
das projekt nutzt auch frontend signup, also denke ich auch für diesen prozess