-
Notifications
You must be signed in to change notification settings - Fork 57
Home
- Packaging as a gem plugin.
- DB backend for view translation.
- Lots of testing.
- Finish up chained backend.
- Setup automatic test running that tracks latest Rails edge.
- Locale + Translation classes
- view translations with yaml (file/dir structure)
- basic model translations (simplest thing possible)
- We will use RSpec for testing, along with a model factory such as Object Daddy or Factorygirl.
- The top-most module will be Globalize.
- The plugin will be distributed as a gem plugin.
We want to establish a convention that will allow Globalize and other i18n plugins to load multiple provided locales for Rails libraries and plugins. Our current idea is to have Globalize slurp up certain files (defined below) for each locale it needs to load. It would then pull in the relevant locale data from those files.
So, if Globalize finds it has to load the German locale, it would slurp locales/de-DE.yml, locales/de-DE/*.yaml and something like locales/all.yml.
This is easy to do, and would give authors the flexibility to put all translations in one file (all.yml), for plugins with just a few translated terms. This would scale to one per-language translations file (locales/de-DE.yml), and up to a bunch of translation files for each locale (locales/de-DE/*.yaml).
YAML-based View Translation
- Locale switching after translated model is already loaded
- The Chained Backend
- Pluralize backend (experimental!)
- Fallbacks
- Caching
- Helpers
- Currency formatting
- Form processing
- View template switching
- Determining locale from HTTP, etc
- Translation view generator — creates controller/view to manage translations online
- Rake tasks
- dump, load translations
- generate migrations
- look for untranslated keys (possibly)
To run the specs go to the projects root dir and run: spec -O spec/spec.opts spec