summaryrefslogtreecommitdiff
path: root/vendor/plugins/globalize2/notes.textile
diff options
context:
space:
mode:
authorhukl <hukl@eight.local>2009-02-07 15:50:40 +0100
committerhukl <hukl@eight.local>2009-02-07 15:50:40 +0100
commit36a2f1f3c085dd81171cf7d8220770d4ff921ab3 (patch)
tree5ded15331b192bf428af4c94d46d1abb28ef0690 /vendor/plugins/globalize2/notes.textile
parentce9645d0092d42c7bf8781378181ffbd4ff3d088 (diff)
added globalize2 plugin as well as some modifications
which use the new translation facilities. backend mostly.
Diffstat (limited to 'vendor/plugins/globalize2/notes.textile')
-rw-r--r--vendor/plugins/globalize2/notes.textile51
1 files changed, 51 insertions, 0 deletions
diff --git a/vendor/plugins/globalize2/notes.textile b/vendor/plugins/globalize2/notes.textile
new file mode 100644
index 0000000..b686f41
--- /dev/null
+++ b/vendor/plugins/globalize2/notes.textile
@@ -0,0 +1,51 @@
1Stopped DB Backend in the middle, here's where we left off:
2
3h1. Some Notes
4
5* Started doing the migration generator in generators/db_backend.rb
6* Translation keys will be in dotted string format
7* Question: Do we need a plural_key column, or can we build it in to the dotted key?
8* We will probably have to code the following methods from scratch, to optimize db calls:
9** translate
10** localize
11** pluralize
12* We should refactor @interpolation@ code so that it can be included into backend code without inheriting SimpleBackend
13** Rationale: interpolation is something done entirely after a string is fetched from the data store
14** Alternately, it could be done from within the I18n module
15
16h1. Schema
17
18There will be two db tables.
19
20# globalize_translations will have: locale, key, translation, created_at, updated_at.
21# globalize_translations_map will have: key, translation_id.
22
23globalize_translations_map will let us easily fetch entire sub-trees of namespaces.
24However, this table may not be necessary, as it may be feasible to just use key LIKE "some.namespace.%".
25
26h1. Caching
27
28We'll almost certainly want to implement caching in the backend. Should probably be a customized
29implementation based on the Rails caching mechanism, to support memcached, etc.
30
31h1. Queries
32
33We'll want to pull in lots of stuff at once and return a single translation based on some
34quick Ruby selection. The query will look something like this:
35
36<pre>
37<code>
38SELECT * FROM globalize_translations
39WHERE locale in (<fallbacks>) AND
40key IN (key, default_key)
41</code>
42</pre>
43
44The Ruby code would then pick the first translation that satisfies a fallback, in fallback order.
45Of course, the records with the supplied key would take precedence of those with the default key.
46
47h1. Misc
48
49We should revisit the :zero plural code. On the one hand it's certainly useful for
50many apps in many languages. On the other hand it's not mentioned in CLDR, and not a real
51concept in language pluralization. Right now, I'm feeling it's still a good idea to keep it in.