I have a Rails 3 app that uses Mongo db but I still wanted to use Tolk for handling translations. I've changed things in a fork that makes Tolk use its own sqlite database instead of the application's db.
You can see the actual commit here: reallyenglish@22ae759
I've tried it successfully on my application and I wondered if this is something you'd be interested in bringing to the main gem. There are a couple of things I'd like to tidy up but if you like this idea in principal, I'll finish up and submit a pull request.
The simplest option might be to just use database.yml. You need one even if you're not using AR in your application - we can just give a sample configuration - and you can set it to use the development config by default and/or show sample configs.
I looked at your commits.
This feature is really nice, but does it still allows to use the same database that the application where tolk is mounted ?
My 'Tolk::Phrase' objects are used by others classes in one of my apps for exemple.
I have some change to finish that will allow you to use your apps db if you need to but by default it will point to tolk.sqlite3. This will be specified in database.yml so you can just do:
If it's just the classes that you need in the app, AR will point to the right database per request.
Personally I think that having it separate by default is the best option - provided it's made clear what's happening and how you set up the alternative.
Having a 'tolk' entry in database.yml also means that it fits with the Rails approach.
Oh for an existing app I think we should use the same database - the same as they have already have setup.
Once I've finished ensuring this is all hooking up correctly I'll work on the setup/update tools - the upgrade should be seamless.
Right - this is all pushed now.
For new installs, it sets up an sqlite3 db and adds a 'tolk' configuration to database.yml.
For existing configurations it doesn't touch database.yml or create anything - this means it'll fall back onto the default configuration, using the current environment's db.
I've added tests for the generators which covers the above functionality. The only thing I'm concerned about now is that the check for an existing installation relies on the developer having created an initializer. That isn't actually required so it might not be the best condition to use.
OK there's a big problem with using sqlite3 - it's case sensitive and all the URL etc are lowercase.
If you were planning to merge in, I suggest not!
If you try and visit a locale like 'zh-TW' for example, the name gets parametized to 'zh-tw'. With sqlite the find_by_name that loads the locale fails.
Do you think a fix is possible ?
Using another way to find the locale, and ensuring there is never two locales with the same lowercase names ?
I just received the desired PR for uppercase locale searching.
Does this fix your case and allows for multiple DB ?
Any news on this one ? @stevebartholomew