Prefer I18n over i18n when referencing internationalization

guides/source/i18n.md

@@ -9,7 +9,7 @@ The process of "internationalization" usually means to abstract all strings and
 
 So, in the process of _internationalizing_ your Rails application you have to:
 
-* Ensure you have support for i18n.
+* Ensure you have support for I18n.
 * Tell Rails where to find locale dictionaries.
 * Tell Rails how to set, preserve, and switch locales.
 
@@ -48,7 +48,7 @@ To localize store and update _content_ in your application (e.g. translate blog
 
 Thus, the Ruby I18n gem is split into two parts:
 
-* The public API of the i18n framework - a Ruby module with public methods that define how the library works
+* The public API of the I18n framework - a Ruby module with public methods that define how the library works
 * A default backend (which is intentionally named _Simple_ backend) that implements these methods
 
 As a user you should always only access the public methods on the I18n module, but it is useful to know about the capabilities of the backend.
@@ -135,7 +135,7 @@ I18n.available_locales = [:en, :pt]
 I18n.default_locale = :pt
 ```
 
-Note that appending directly to `I18n.load_path` instead of to the application's configured i18n will _not_ override translations from external gems.
+Note that appending directly to `I18n.load_path` instead of to the application's configured I18n will _not_ override translations from external gems.
 
 ### Managing the Locale across Requests