Ich habe bei Microsoft Connect eine Anfrage bezüglich der Formatierung von Daten erhalten (" DateTime-Formatierung sollte neu berechnet werden das richtige Suffix für den Tag "). Im Grunde wollte ich einen Formatierungsstringcode haben, um das Suffix zur Tagesnummer hinzuzufügen. So würde "1 Jan" formatiert werden "1. Jan" und "2 Jan" formatiert "2. Jan" etc.
Dies ist ziemlich einfach für den englischen Fall, aber Microsoft hat die Idee mit der Begründung abgelehnt, dass es zu schwer wäre, sie zu internationalisieren.
Ich habe mich nur gefragt, ob die Leute zustimmen, dass es für Microsoft vernünftig ist, englischen Programmierern, die nur für einen englischen Markt schreiben, das Leben schwerer zu machen, nur weil sie den nicht-englischen Markt nicht bedienen können?
Bearbeiten: Ok, ich akzeptiere das Argument, dass es dort Framework gibt, um zu tun, was sie wollen. Ich habe mehr nach einem ideologischen Sinn gefragt. Denken Sie auch daran, dass es einen leichten Fallback für nicht-englische Kulturen gibt, der nichts hinzufügen soll, was die Leute nicht schlechter macht, als sie es jetzt sind.
Edit 2: Für mich ist das mehr als eine Stunde Arbeit. Ich muss Code unterstützen, der ungefähr so aussieht:
%Vor%Ich habe keine Kontrolle über den Inhalt der Ressourcendatei und die Ressourcenkette sieht oft so aus: "Das Datum sollte nicht vor {0: D}" sein. Dazu müsste ich meine eigene IFormatProvider-Klasse implementieren, die alle Formatierungszeichenfolgen unterstützen muss, die Microsofts Formatierer akzeptiert. Microsoft scheint keine einfache Möglichkeit gegeben zu haben, ihren Formatierer durch Vererbung zu erweitern.
1: Es ist ihr Rahmen, alles, was sie tun, ist per definitionem vernünftig. Sie sind nicht verpflichtet, etwas anzubieten, was ihnen nicht gefällt.
2: Funktionen, die nicht internationalisiert werden können, sind grundsätzlich nutzlos. Wenn sie es nur für Englisch hinzufügen würden, würden sie nur erreichen, dass der Rest der Welt verlangen würde, dass es internationalisiert würde, und plötzlich würden sie schlecht aussehen, weil sie dem Rest der Welt eine minderwertige Behandlung geben würden.
3: Es ist schwer zu internationalisieren. Sie können nicht davon ausgehen, dass jede Sprache einfach ein Suffix hinzufügt. Es könnte ein Präfix sein, oder es könnte komplett verschiedene Teile des Satzes ändern. (Oder, wie ein anderes Plakat hervorhob, es könnte "erster" statt erster sein, also gibt es auch im Englischen keine festen Regeln. Warum sollten sie Ihre willkürliche Regel implementieren, aber nicht andere, gleichwertige für Englisch? )
3b: Obwohl Ihnen das natürlich egal ist, vermarktet Microsoft .NET als Framework für Internationalisierung. Das bedeutet, dass sie 90% der Welt nicht einfach ignorieren können, um Ihren Bedürfnissen zu entsprechen.
4: Es würde eine Weile dauern, die englische Version für sich selbst zu programmieren, oder? ;)
5: Es hat nichts mit DateTime zu tun. Es ist eine allgemeine Eigenschaft der String-Formatierung von Zahlen im Allgemeinen .
6: Ihre Annahme, dass "wenn sie die Funktion für Englisch hinzugefügt hätten, wäre niemand schlechter dran als jetzt" ist falsch. Entwickler verlassen sich im Allgemeinen auf .NET, um sich korrekt zu verhalten. Wenn Ihr Formatierungsvorschlag hinzugefügt wurde, würden Entwickler natürlich erwarten, dass er für alle Sprachen und Ländereinstellungen funktioniert, und würde daher eine ungültige oder unerwartete Ausgabe für alle nicht-englischen Sprachen generieren, wenn der Entwickler kein Problem erwartet.
"Ich habe mich nur gefragt, ob die Leute zustimmen, dass es für Microsoft vernünftig ist, englischen Programmierern, die ausschließlich für einen englischen Markt schreiben, das Leben schwerer zu machen, nur weil sie den nicht-englischen Markt nicht bedienen können?" / em>
Ich denke du bist ein bisschen extrem und meiner Meinung nach ist es wirklich ein Randfall. Diese Art der Datumsformatierung ist vergleichbar mit der Frage nach Microsoft für einen Post / Postleitzahl-Formatierer oder eine Adressklasse. Sicher, es gibt eine Konvention für die meisten Länder zum Formatieren von Postleitzahlen und Adressen, aber das bedeutet nicht, dass MS es implementieren muss. Sie haben das Framework zur Hand, um diese Art von Datenstrukturen zu erstellen.
Also ist das richtige Englisch für das erste, zweite und dritte Element einer Liste nicht das erste, das zweite und das dritte?
Ich kann sehen, was Sie meinen, aber es ist mehr eine unterstützende Kontraktionen "kann, wird nicht, ist nicht" Problem dann ein Datum Zeit Problem.
Ich denke, sowohl MS als auch Sie haben gute Punkte gemacht.
Ich stimme eher mit MS überein. Das Problem macht nicht das Leben für nicht-Englisch-Software schwieriger. Das eigentliche Problem wäre, dass die neuen Methoden nicht in verschiedenen Sprachen funktionieren würden, und das ist nicht akzeptabel. Eine Sache hat keine Funktion, eine andere hat eine Funktion, die in bestimmten Fällen nicht funktioniert.
Ich vermute jedoch, dass es möglich wäre, sprachspezifische Funktionen zu erstellen. Vielleicht etwas wie localization.English.DateFormatter Das wäre ein guter Kompromiss, aber es könnte dazu führen, dass das Schreiben von Software auf lange Sicht schwieriger zu lokalisieren ist.
Nur um Ihnen eine Vorstellung davon zu geben, wie schwer das ist.
Der 1. Januar ist nur für britisches Englisch korrekt. Die korrekte Form in US-Englisch ist der 1. Januar.
Die Kanadier wahrscheinlich Kompromiss mit 1er Janvier.
Die C-Funktion zum Formatieren von Datumsangaben ist strftime (). Dies nimmt eine Formatzeichenfolge mit ' %x ' Notationen, um die Teile des zu formatierenden Datums und deren Formatierung anzugeben. Es wäre möglich, ' %o ' als Formatelement für die Ordinaltagnummer mit Ziffern (1., 2., 3., ...) und eine Alternative (logisch ' %O ') hinzuzufügen, aber ich denke, das ist bereits in user) für die geschriebene Version (first, second, ...). Dies könnte dann genauso globalisiert werden wie jeder andere Teil der Datumsformatierung. Das Standardergebnis für ' %o ' könnte durchaus 'kein Suffix' sein, wenn das Gebietsschema keine Informationen darüber enthält, wie Ordnungszahlen geschrieben werden; Sie könnten sogar die Nummer ohne Suffix für die 'buchstabierte'
Die entsprechende Funktionalität existiert in anderen Sprach-Frameworks - sie könnte in jedem von ihnen leicht bereitgestellt werden.
(Wenn jemand Monate - den ersten Monat des Jahres 2009 - ordinalisieren wollte, dann brauchen Sie ein anderes Symbol.)
Microsoft ist nicht verpflichtet, Arbeiten für Sie durchzuführen. Es wird eines dieser Dinge sein müssen, die Sie selbst implementieren, zusätzlich zu ihrem Framework.
Tags und Links .net internationalization language-features