Permalink
Browse files

add quote from wikipedia about I18n and L10n

  • Loading branch information...
1 parent 44a8319 commit 99d16fa40e308e91cc647d516c27917ade660ffc Sven Fuchs committed Dec 16, 2008
Showing with 6 additions and 1 deletion.
  1. +6 −1 railties/doc/guides/source/i18n.txt
@@ -103,7 +103,7 @@ Now you've initialized I18n support for your application and told it which local
=== Internationalize your application
-The process of "internationalization" usually means to abstract all strings and other locale specific bits out of your application (TODO reference to wikipedia). The process of "localization" means to then provide translations and localized formats for these bits.
+The process of "internationalization" usually means to abstract all strings and other locale specific bits out of your application. The process of "localization" means to then provide translations and localized formats for these bits. (0)
So, let's internationalize something. You most probably have something like this in one of your applications:
@@ -515,6 +515,7 @@ Rails uses fixed strings and other localizations, such as format strings and oth
TODO list helpers and available keys
+
== Customize your I18n setup
=== Using different backends
@@ -576,6 +577,10 @@ I18n.t :foo, :raise => true # always re-raises exceptions from the backend
== Footnotes
+TODO make these anchors
+
+(0) Or, to quote http://en.wikipedia.org/wiki/Internationalization_and_localization[Wikipedia]: _"Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text."_
+
(1) One of these reasons is that we don't want to any unnecessary load for applications that do not need any I18n capabilities, so we need to keep the I18n library as simple as possible for English. Another reason is that it is virtually impossible to implement a one-fits-all solution for all problems related to I18n for all existing languages. So a solution that allows us to exchange the entire implementation easily is appropriate anyway. This also makes it much easier to experiment with custom features and extensions.
(2) Other backends might allow or require to use other formats, e.g. a GetText backend might allow to read GetText files.

0 comments on commit 99d16fa

Please sign in to comment.