Ruby on Rails
Posts 1-7 of 7
-
Clemens HelmThe company name is only visible to registered members.Haml-Templates mit haml-i18n internationalisieren
Ich habe kürzlich ein Gem namens haml-i18n entwickelt, um die Internationalisierung von Haml-Templates leichter und lesbarer zu machen:
http://www.rails-troubles.com/2011/11/internationalize-haml-...
Die Funktionalität ist noch etwas begrenzt, darum freue ich mich über Mithilfe und Feedback.
- 19 Dec 2011, 5:07 pm
-
Dr. Peter Horn Premium MemberThe company name is only visible to registered members.Re: Haml-Templates mit haml-i18n internationalisieren
Hiho!
Den i18n Syntax Krempel zu vereinfachen finde ich super, aber ich glaube Dein Ansatz geht mir zu weit -- insbes. weil man ihn ja implizit ständig benutzen 'muss', wenn ich das richtig sehe.
Ist vielleicht nicht ganz zu Ende gedacht, aber könnte man nicht den Sonderzeichen-Overkill durch Methodenaufrufe ersetzen, also statt
t('moo')
ein
tt.moo
und statt
t('moo', dog: 'woof')
ein
tt.moo dog: 'woof'
das liest sich doch einigermaßen elegant. tt müsste man halt dafür komplett leer räumen, aber da sehe ich (außer vll. bei object_id und so) kein riesiges Problem. Scoping könnte man mit [] machen, also
tt['do.re.mi']
um den Scope für den Rest des Temples zu setzen, ansonsten geht natürlich auch
tt.do.re.mi.moo
Was meint Ihr?
Gruß, Peter
PS: Ach ja -- und das ist dann auch nicht auf haml beschränkt ;) Da ich ständig mindestens haml und erb parallel benutze, wäre mir das sehr lieb.
This post was modified on 19 Dec 2011 at 09:34 pm.- 19 Dec 2011, 9:33 pm
-
Clemens HelmThe company name is only visible to registered members.Re^2: Haml-Templates mit haml-i18n internationalisieren
Hi Peter,
Danke für deine Antwort! Worum es mir wirklich ging, war, natürlichsprachige Templates ohne verworrene Syntax zu schaffen. An deinem Beispiel kann ich ehrlich gesagt nicht so wirklich Vorteile erkennen, da du die Syntax ja selbst als Methodenaufruf so schreiben kannst:
t 'moo', dog: 'woof' vs. tt.moo dog: 'woof'
Dennoch bleiben deine_i18n_keys_etwas_unschoen.
Klar, wenn du erb und haml einsetzt, wirst du die Vorteile nur für Haml haben. Ich habe schon überlegt, die Logik aus dem Plugin zu extrahieren und dann Hooks für verschiedene Templating-Engines (Erb, Haml, Slim) anzubieten.
Zum ständig benutzen 'müssen': Natürlich, wenn du haml-i18n verwendest, wird für jeden normalen Text ein i18n-lookup gemacht. Aber hast du in internationalisierten Apps noch nicht-internationalisierte Texte in den Templates?
Liebe Grüße!
- 20 Dec 2011, 08:05 am
-
Dr. Peter Horn Premium MemberThe company name is only visible to registered members.Re^3: Haml-Templates mit haml-i18n internationalisieren
Hey Clemens,
Danke für deine Antwort! Worum es mir wirklich ging, war, natürlichsprachige Templates ohne verworrene Syntax zu schaffen.
Point taken.
An deinem Beispiel kann ich ehrlich gesagt nicht so wirklich Vorteile erkennen, da du die Syntax ja selbst als Methodenaufruf so schreiben kannst:
Was ich daran immer unglücklich finde ist, dass die Klammerei es hässlich macht, es aber ohne Klammern in komplexeren Kontexten schnell gruselig unklar wird. (my 2 ct.)
Dennoch bleiben deine_i18n_keys_etwas_unschoen.
Ack. Mir ging's primär um das Sonderzeichen-Loswerden.
Bei einem Beispiel wie 'User' sehe ich das ja auch ein, aber man hat doch häufig eher Dinge wie
"Thank you for your Order"
und da landet man dann ja auch in Deinem Vorgehen bei irgendwelchen Kürzeln, oder?
Was mir dabei auch (selbst ohne die Kürzelproblematik) nicht gefiele ist, dass "lange" Texte auf eine gewisse Art "instabil" sind. Wenn da t("ein_komisches_kurz_ding") steht, weiß ich, dass ich das nicht bearbeiten darf, ohne dasses knallt.
Zum ständig benutzen 'müssen': [...]
Guter Punkt :)
Viele Grüße, Peter
- 20 Dec 2011, 09:32 am
-
Dr. Peter Horn Premium MemberThe company name is only visible to registered members.Re^4: Haml-Templates mit haml-i18n internationalisieren
Moinsen!
Clemens, sorry -- ich gehe hier ein bisschen off-topic. Ich habe -- nur zum Spaß -- mal die Idee umzusetzen versucht, das hat einen gewissen Charme, finde ich.
https://gist.github.com/1502996
In den Views kriegen wir dann:
<%= tt.activerecord.attributes.customer.firstname %>
Vorname
<% t2 = tt.activerecord.attributes.customer %>
<%= t2.firstname %>
<%= t2.lastname %>
Vorname
Nachname
<%= tt.foo.bar.firstname %>
translation missing: de.foo.bar.firstname
Gruß, Peter
- 20 Dec 2011, 9:07 pm
-
Clemens HelmThe company name is only visible to registered members.Re^5: Haml-Templates mit haml-i18n internationalisieren
Peter, sorry für die späte Antwort!
Ja, sieht nicht schlecht aus!
Ich persönlich versuche immer, nur den relativen Pfad ( t '.firstname' ) zu einem i18n-Key zu verwenden. Einerseits ist er kürzer, andererseits strukturierst du dadurch automatisch deine i18n-Files besser.
Für meinen Geschmack wäre es also eine Verbesserung, wenn tt.firstname zuerst einen Lookup auf den relativen Pfad macht und nur wenn dieser nicht vorhanden ist, den absoluten Pfad auflöst.
Die Variante mit der Variable t2 finde ich nicht schlecht, was hältst du aber von
<% tt.activerecord.attributes.customer do |customer| %>
<%= customer.firstname %>
<%= customer.lastname %>
<% end %>
In HAML reduziert es sich auf ein schönes
- tt.activerecord.attributes.customer do |customer|
= customer.firstname
= customer.lastname
Was ist der Vorteil daran? Der Scope ist sehr klar ersichtlich. Bei einer Variablendeklaration dagegen ist die Versuchung größer, die Variable schon weit vorher im Template zu deklarieren, was die Lesbarkeit reduziert, weil mitunter nicht auf den ersten Blick klar ist, worauf diese Methoden nun aufgerufen werden.
Vielleicht finden wir ja die perfekte Syntax noch und machen gemeinsam ein neues universales Gem ;)
This post was modified on 11 Jan 2012 at 01:31 pm.- 11 Jan 2012, 1:30 pm
-
Clemens HelmThe company name is only visible to registered members.Re^6: Haml-Templates mit haml-i18n internationalisieren
XING zeigt leider die Einrückungen nicht an, aber ich denke, es ist trotzdem klar…
- 11 Jan 2012, 1:32 pm
