On the one hand, I like to encourage programmers who bake in internationalization, even in trivial projects.
On the other hand, I have dealt with far too many programmers who think romanizing Japanese is an acceptable alternative because all dem squigglies are hard.
This isn't a pedantic distinction: 'HAI' is not an acceptable localized message. It's just not. It would be funny except it happens in systems that got contracted out for six figures.
Would katakana be accepted (as opposed to full kanji)? Can't speak for anyone else, but as a non Japanese speaker, I find katakana a lot easier to work with, but am unsure whether it looks amateurish to use it exclusively in Japanese eyes.
The different Japanese writing systems each have their purpose. It's a bit like asking "Would uppercase-only be accepted?" when translating to English. It depends what you're translating, but in general if you only use a small subset of a language's writing system you're not going to come across as a complete translation.
Why is Katakana easier to work with? I mean, usually my code is either unicode-safe... or it isn't. I've never ran into "kind of unicode-safe as long as the character doesn't have too many lines" ;)
My knowledge of Japanese is poor, but I know the romanization of many of the sounds used. For example, "kaze wo atsumete". If I type that on a Japanese keyboard, I get the katakana to match. Working out what the equivalent kanji are (if any in this case?) would be impossible to me.
That remains barely, and I stress barely, acceptable in embedded devices which just don't have the resources available to physically display and/or print all of the kanji they would need to accomplish their function. (Not exactly uncommon in things which are capable of printing receipts, which might need a set of kanji which could be almost unbounded at design time -- bank ATMs have to be able to print every name, etc.)
If, for example, you are producing the display logic for a printer it may not make economic sense to give it the necessary capability to write 用紙がありません。 so instead you write ヨウシガアリマセン。 in half-width characters. (Incidentally, that means "out of paper". I hate printer error messages because they are typically scrolling and I can't read scrolling solid blocks of katakana as fast as Japanese people. Funnily enough, my coworkers have the same complaint.)
If you are using a general purpose operating system, putting everything in kana/romaji is not acceptable. My bosses have the quite sensible notion that we are paying for a 100% job not a 100%-of-the-convenient-to-you job.
require 'sinatra'
get '/' do
%{<html><body>
<h1>#{Time.now.mday == 25 && Time.now.month == 12 ? "YES" : "NO"}</h1>
</body></html>}
end
Sure, no internationalization or adaptation to local time, but I'd arrogantly assume most Internet users can understand YES and NO as well as I understand JA and NEIN or OUI and NON (apologies to speakers of non-Latin derived languages.. :))
This will return the wrong answer if the first expression is evaluated on, say, November 25th and the second half of the expression isn't evaluated until December 1st. Very buggy ;)
Sure, it is a short code snippet that works some of the time, but the original was trying to solve a more difficult problem. This code doesn't even try.
What good is pretty code if it only runs on localhost?
Oh, and if you really do only care about localhost, there isn't much difference between the Sinatra/Ruby code and PHP:
If you stuck to just UTC, you could run it anywhere and it'd be logically (though not pragmatically) correct.
In any case, I was being flippant because I thought the original was a joke of sorts. It was amusingly overengineered, so I thought I'd go too far in the opposite direction to play devil's advocate, as it were.
It's missing some internationalization and it'll probably fail every now and then (but less than 0.03% of the time) but you'll have to agree it is very concise.
Why not just do a static version of the site for 364 days of the year and just git push on the hour of xmas? It'd be good enough, infinitely more scalable, and offers the benefit of looking into past revisions to find previous dates xmas occurred on.
Or additionally, he could just shutdown the site on xmas day and post a disclaimer for the other 364 days that the site has a 99.997% success rate. (or a 0.003% failure rate)
Yeah, even without doing the computation or just noting that 365 < 1000, it would be pretty absurd to be able to do far better than any Amazon S3 guarantee (to give one example) while still being able to be "down" for an entire day!
Even if it's a small project the code is mediocre at best. For example, isn't there a library for PHP that handles internalization and why do internalization in both JavaScript and PHP (and no is only internalized in the JavaScript version...)
Lastly it's a really bad idea to determine language based on IP, a much safer way is to use the browser's language (ACCEPT_LANGUAGE header).
27 comments
[ 2.8 ms ] story [ 76.3 ms ] threadOn the other hand, I have dealt with far too many programmers who think romanizing Japanese is an acceptable alternative because all dem squigglies are hard.
This isn't a pedantic distinction: 'HAI' is not an acceptable localized message. It's just not. It would be funny except it happens in systems that got contracted out for six figures.
If, for example, you are producing the display logic for a printer it may not make economic sense to give it the necessary capability to write 用紙がありません。 so instead you write ヨウシガアリマセン。 in half-width characters. (Incidentally, that means "out of paper". I hate printer error messages because they are typically scrolling and I can't read scrolling solid blocks of katakana as fast as Japanese people. Funnily enough, my coworkers have the same complaint.)
If you are using a general purpose operating system, putting everything in kana/romaji is not acceptable. My bosses have the quite sensible notion that we are paying for a 100% job not a 100%-of-the-convenient-to-you job.
This will return the wrong answer if the first expression is evaluated on, say, November 25th and the second half of the expression isn't evaluated until December 1st. Very buggy ;)
Sure, it is a short code snippet that works some of the time, but the original was trying to solve a more difficult problem. This code doesn't even try.
What good is pretty code if it only runs on localhost?
Oh, and if you really do only care about localhost, there isn't much difference between the Sinatra/Ruby code and PHP:
In any case, I was being flippant because I thought the original was a joke of sorts. It was amusingly overengineered, so I thought I'd go too far in the opposite direction to play devil's advocate, as it were.
Sorry, I'll shut up now :p
Lastly it's a really bad idea to determine language based on IP, a much safer way is to use the browser's language (ACCEPT_LANGUAGE header).
http://github.com/isit/christmas/tree/master/iic.js
132 "CN": "BÙ SHÌ", // China (Mandarin)