Comments

Leave a response

1. Thiago Taranto on 02 Sep 00:45:
   

   That’s realy nice! Now I’ll start use it. Thanks guys!

2. Thiago Taranto on 02 Sep 01:00:
   

   I just finished the translation to Brazilian Portuguese, I hope this help someone else. Thanks again guys!

3. Dr Nic on 02 Sep 02:10:
   

   Poor Tobi. He obviously didn’t read Joel’s email first.

4. Chris Carter on 02 Sep 05:16:
   

   Can it handle sorting and searching in multiple languages properly? Especially non-latin languages?

5. Lon on 02 Sep 06:25:
   

   Congrats to Tobi and crew!

   I have been using the technique Thomas Fuchs published last October – since well – last October.

   Guess I need to do a svn revert now that Joel set me straight?

6. Eric Hodel on 02 Sep 07:40:
   

   Uh, we’ve been doing this for over a year now on 43 Things. http://es.43things.com/zeitgeist (and others)

7. Ervin J on 02 Sep 08:17:
   

   Maybe I am the ignorant one, but it seems to me that none of those languages needs more than the 8-bit ANSI character set.

   Only when I’ll see Asian languages, it will be true internationalization.

8. Josh H. on 02 Sep 12:15:
   

   Actually, as great as Shopify is, there’s nothing groundbreaking about an internationalized Rails site, or even an internationalized ecommerce site. http://rashgash.com has been up and running since April, and it even does right-to-left. The secret, of course, is http://globalize-rails.org/wiki/.

9. since1968 on 02 Sep 12:50:
   

   I’m a Rails user, so don’t flame me; this is an honest question:

   From the Shopify blog it looks like they’re storing the checkout language in tokens and grabbing the relevant token from the database based on the desired language. That’s a great feature but I don’t see how their i18n addresses the issue of UTF8 support, which is the core of the critique. Who ever said you couldn’t store chunks of UTF8 in your database with Rails?

   Are you (or they) claiming the UTF8 text is now safe to use with validates_length_of, etc.?

10. Venkat on 02 Sep 14:07:
    

    Same question as previous post. Can it do sorting and searching in Asian languages? That would clearly make a huge difference in pushing it to the banks.

11. ilya on 02 Sep 18:27:
    

    wow, not only shopify went international, the germans also chucked the Euro and went for the dollar!

    € => $

12. Jonathan Rockway on 02 Sep 18:57:
    

    I’m not a Rails user, so feel free to flame me :)

    The issue with ruby isn’t so much storing UTF-8 octets in a database and echoing them back to the browser. Anything can do that.

    The problem starts when you have data sources in various charsets. Maybe the user is in a non-UTF-8 locale, and has some 8-bit characters in the config file. That’s a problem. Also, if the end user’s browser doesn’t support UTF-8, you have another problem. The data coming in in requests won’t be UTF-8, so you’ll have to deal with that. The data going back also can’t be UTF-8 if the browser can’t Accept-encoding UTF-8. (It could be, but the user will just see garbage.) etc. etc.

    Finally, not having unicode support in ruby means that you can’t properly alphebetically sort things in multiple languages, use unicode in regular expressions, etc.

13. tobi on 02 Sep 19:13:
    

    since1968: This is correct. We store tokens in the database and match them up with translated ones ( using the english sentence as key ).

    Our database is UTF-8 and ruby does nothing bad to the strings coming from database to the browser.

    This doesn’t address validates_length_of but how often do you really need this…

    Ruby’s issues with UTF-8 are blown out of all proportions in my eyes. At least for web applications which store all their data in UTF-8 aware storage.

    By the way: We already got German, Portuguese ( Brazil ), Swedish and two different takes on French support contributed in less then 24 hours :)

14. Robby Russell on 02 Sep 20:12:
    

    i18n in Ruby on Rails isn’t really that difficult to do. At PLANET ARGON, we have done a few projects that supported multiple languages. The last one that we did supported the following languages:

    ENGLISH, ČESKY, DEUTCH, ESPAÑOL (ESPAÑA), ESPAÑOL LATINO, FRANÇAIS, ITALIANO, MAGYAR, POLSKI, PORTUGUÊS (BRASIL), PORTUGUÊS (PORTUGAL), РУССКИЙ, TÜRKÇE, ภาษาไทย, 简体中文 , 繁體中文, 日本語, and 한국어.

    We used the Globalize plugin for this.

15. newland archer on 02 Sep 22:01:
    

    I need to provide a web application which gives external translators the ability to translate text strings found in a desktop application we sell. The database stores the strings and then provides a way to download the translations as XML files which are loaded into the application. I’m not that worried about the database interface, which seems like it will probably work. i’m more worried about if ruby will write out the XML files correctly.

    The languages of most importance are:

    1. english (no problem) 2. spanish 3. portuguese 4. japanese 5. russian

    I can get the framework for editing done in a couple of hours, as I have rails components from another project. However I don’t have a bunch of time to spend on potential unicode problems. this needs to be up and running alongside a new revision of our desktop application which is set to launch Sometime Soon.

    I also could do this in python or perl, which I know already, and which I know support the languages I need to support. However I’d love to do it in rails as it would more easily integrate with the rest of our web stuff. This needs to be ready to go most likely by the end of next week.

    I can’t seem to find an straightforward answer anywhere. Can anyone advise me as to whether or not I should attempt this with rails, or if i should just get a quick and dirty version done in python and then move it over to rails when all the unicode stuff is sorted?

16. Eric Hodel on 02 Sep 23:27:
    

    In 43 Things we let the database do the sorting.

17. Rob P on 03 Sep 06:32:
    

    Judging from these comments, part of the problem is that the core team (David) doesn’t understand what is really necessary for internationalization to be done correctly.

18. rick on 03 Sep 07:24:
    

    Rob: care to back that statement up? Or, judging by your comment I’d think you don’t understand it either :)

19. Thomas on 03 Sep 15:32:
    

    This post, for those who don’t realize it, is simply DHH reaction (or more so, over-reaction) to Joel’s comment that Ruby has poor unicode support.

    http://joelonsoftware.com/items/2006/09/01.html

    And as many have already stated in this post, YES Ruby does have poor unicode support … as well as that the Ruby language is slow.

    Now, if DHH was mature and instead of flaming the repected Joel Spolsky at his blog at loudthinking.com, he should have simply stated counter examples to Joel’s post about Ruby.

    I really don’t understand why DHH got so upset about Joel’s comments. Joel wrote 8 paragraphs about various languages, only 1/2 of 1 paragraph was about Ruby. His comments were not an attact at all about Ruby. He simply stated the truth about the language.

20. V on 03 Sep 22:07:
    

    The truth is Ruby has poor unicode support and Ruby is slow. Accept it and fix it.

21. Gabe on 03 Sep 23:57:
    

    Why does this have to turn into a holy war?

    We know Ruby doesn’t really support utf-8 and that’s a hindrance to doing internationalization.

    We also know that these problems can be worked around, even if it’s less than ideal.

    I look forward to the day that Ruby supports unicode fully, but lets be clear: it’s Matz’ problem not DHH’s. So DHH likes to get involved in (or start) flame wars, nobody’s perfect.

22. Thijs van der Vossen on 05 Sep 06:40:
    

    ‘Also, if the end user’s browser doesn’t support UTF-8, you have another problem.’

    If somebody is silly enough to use a browser that doesn’t support UTF-8 then that’s their problem.