Closed lassebunk closed 10 years ago
i'd wondered if something like this could happen. i don't think this is the thing that i was thinking of though. there's a bit of duplication between the html entities and character key/values. it's possible for a user to put different values for both contexts. i half wondered if making the html entity values point to the character hash/values where applicable is a good idea.
also this might just be what it is btw. if you have nothing for the values in html_entities [or they're wrong], then it would hit the transliteration for default. might not be it but could be. what's yr thoughts on changing this btw.
hey i just caught that you left the html entities translation inside the da.yml as and. i'm toying with a better fix on this though.
my other solution wasn't great so it's prolly just as simple as making sure the locale is correct. wanna look at the other da html entities before i push this to a new gem release?
D-O-H :smile: yeah I'll take a look and fix it. Thanks.
i'd love something more clever that at runtime looks upstream to the translations but there's so much interconnection there that it seems a giant pain.
Not sure I understand fully – could you explain it? The da.yml looks good now – thanks :+1:
like when we look up the transliterations for html entities, instead of looking them up in a table, we say 'look it up as this key and value on another table'. table == hash, whatever. but there's whitespace issues, keys not having same names, etc. seems like a big headache that i dont' want to touch atm. messing with ruby 1.9.2 and rails 2.3 encoding errors on non en-us requests atm. blech.
@lassebunk, this works now with fixed yml, right? i'm thinking of not touching this unless it's still a problem.
Yes, this works after you fixed the (my) typo in the yaml. Thanks :+1:
In Danish, e.g.
&
doesn't get translated to the correct word:They should be the same.
I will try looking into this.