GX-Task #68071
offen
einheitliche Schreibweise des Sprach-Code beim Anlegen und Bearbeiten von Sprachen / Uniform notation of the language code when creating and editing languages
0%
Beschreibung
einheitliche Schreibweise des Sprach-Code beim Anlegen und Bearbeiten von Sprachen
Der Sprach-Code muss ein einheitliches Format haben wie z.B. der ist immer in Großbuchstaben (DE) und niemals klein geschreiben (de)
Wir haben an vielen Stellen im Quelltext ein Problem das das immer wieder unterschiedlich behandelt wird und damit Probleme verursacht wo dann Texte nicht gespeichert oder gelesen werden und damit verloren gehen.
Wir müssen dann ggf. alle Stellen im HTML oder PHP prüfen und entsprechend dem geforderten Format anpassen und entsprechende Prüfung einbauen um das Format zu forcieren.
Uniform spelling of the language code when creating and editing languages.
The language code must have a uniform format such as the code is always in capital letters (DE) and never lowercase (de)
We have a problem in many places in the source code that this is always treated differently and thus causes problems where then texts are not saved or read and get lost.
We may then have to check all the places in the HTML or PHP and adjust them according to the required format and include appropriate checking to force the format.
Zugehörige Tickets
Von Till Tepelmann vor fast 4 Jahren aktualisiert
- Beziehung mit GX-Bug #68068: Contents of Products Contents not loading when re-editing/Inhalte unter Artikelinhalte werden beim erneuten Bearbeiten nicht geladen wurde hinzugefügt
Von Mirko Janssen vor fast 4 Jahren aktualisiert
This problem occurs when data providing (in the HTTP controller) and processing (in the template) use different formats for the language code. In general, it's ok to change the format (uppercase) of the language code if there is a specific reason, but in these cases, the developer must assure that these formats match.
To store all language codes in the database in an uppercase format is a business rule and it must be ensured, that this business rule is added to the domain logic (legacy and refactored services). How to, depends on how strict this should be implemented ... it's possible to capture wrong user input and always map these, which results in additional logic (compared to the domain logic), which must be added to the HTTP controllers or JS handlers.
Von Ulrich Wenk vor fast 4 Jahren aktualisiert
- Status wurde von Gemeldet zu Anerkannt geändert
Von Moritz Bunjes vor