Better storage of translations

[Maciej Piechotka]

Currently the storage in the database has relativly low usability.
There is several ways of improving it:

1. Import of gettext files
Pros: Many tools are specified to edit po files. This feature could
come with the export of the pot files.
Cons: Necessity of writing the po parser

2. Providing some other format
Pros: It can be more easy to parse than po
Cons: It has all cons of po and no pros

3. The simple controller and/or scaffold
Pros: Simple, fast and user frienly
Cons: Why to do it when there is a lots of already working tools
[operating on po] - which will do it better?

4. Other?

The feature should came around 0.0.3-0.0.5 depending on difficulty of
the task (and the devs time resources)

Regards

[Alex Coles]

Hi Maciej,

I strongly favour option 1. In fact, what would be great would to
provide either a binary or rake task that allows import of PO files or
YAML files into the database.

This effectively relegates the database to a 'cache' - the developer
can use PO or YAML files (and I am working on Java ResourceBundles)
directly with the PO and YAML providers, or can use import them and
use the database providers.

I know Ruby Gettext provides support for creating po-files from AR
(although I don't know how that works in practice)? I am guessing it
doesn't work the other way around.
http://www.yotabanana.com/hiki/ruby-gettext.html

Alex

[Maciej Piechotka]

I'll try to do it. However I'm not sure which will be the faster
(probably database).

I'll try to parse gettext files.

Regards

[Alexander Coles]

On Jun 2, 2008, at 1:10 PM, Maciej Piechotka wrote:
>
> I'll try to do it. However I'm not sure which will be the faster
> (probably database).
>
> I'll try to parse gettext files.

Are you going to target this to release 0.0.3?

[Maciej Piechotka]

My be. As parser is nearly finished by now.

Regards

[Maciej Piechotka]

On Mon, 2008-06-02 at 13:12 +0200, Alexander Coles wrote:
>

Probably not unless I finish before Thursday. The priority is the new
parser.

I have a question about the place of the importing code:

1. In the provider classes (as optional methods)
Pros: Simple, using already established classes. They also know the best
about state.
Cons: Unless I find something it seems that the gettext would have to
have 2 mixed implementations - gettext gem, which use native gettext,
and our parser. It may provide a confusion within the code.

2. In separate classes (Importers/Exporters?)
Pros: Split the different functions. Do not confuse in native/our own
mixing as with the gettext.
Cons: Against SPOT.

3. Other?

Regards