search

taoensso / tower

i18n & L10n library for Clojure/Script
https://www.taoensso.com/tower
Eclipse Public License 1.0
278 stars 24 forks source link

Using standard Resouce Bundles as dictionaries #33

Closed m0smith closed 10 years ago

m0smith commented 10 years ago

I would like to separate out the dictionary for each locale into a separate file either as a EDN (clojure map) or a standard resource bundle.

ptaoussanis commented 10 years ago

Hi Matthew, sorry for the delayed response - you caught me on vacation :-)

Could you describe your use case in a little more detail - is there a particular reason you want the locales separated like this? What would you suggest the API look like for specifying the separate files that need (re)stitching together? Have you considered doing the separation on your end (i.e. outside of Tower) and auto-merging the maps to create a single resource for Tower?

Am juggling quite a few priorities atm (incl. a vacation backlog) so the more concrete you can be, the likelier it is I'll be able to help out quickly :-)

Cheers!

m0smith commented 10 years ago

My thought is that the dictionary will grow quite large with a lot of resources and languages. Also, since different people will be doing the translations, it would be good to have separate files to make this more manageable. This follows the default behavior of Java ResourceBundles.

The change to API would be to change :dictionary to take any function rather than a map. Then there would need to be a function written to lookup the resource using the same rules as the ResourceBundle. This would allow users to provide additional functions to do the lookup as needed (for example I was thinking of storing the translations in a database rather than a flat file).

If you don't mind I could take a stab at it.

ptaoussanis commented 10 years ago

Also, since different people will be doing the translations, it would be good to have separate files to make this more manageable.

Hmm, okay - quick thoughts on this:

  1. In most production environments I believe folks will probably be using proper translator tools and file formats. In these cases the .clj dictionary is really an implementation detail to export/import to/from. Is there a particular reason you would want translators to be working directly with the .clj dictionary?
  2. Since the .clj dictionary is just a Clojure file, we do have the ability to use whitespace and/or comments to organize the file structure. In my particular use cases, that's been quite sufficient for relatively small dictionaries (~ few hundred entries by < dozen langs).

Am not against the idea, just playing devil's advocate.

The change to API would be to change :dictionary to take any function rather than a map.

That's an interesting idea which I hadn't thought of. So do I understand correctly that you're proposing we support 3 forms of :dictionary value?:

  1. A map.
  2. A resource name string pointing to a .clj file that reads to a map.
  3. An arbitrary nullary fn that should return a map.

Another idea might be a vector of resource names (as in #2) to auto merge.

If you don't mind I could take a stab at it.

I'm hesitating a little atm since I'm not 100% convinced yet that the extra complication would be a real win in most cases (that is over just exporting/importing to/from traditional translating formats where we'd get a lot of ancillary benefits like translation diffs and inheritance)...

Could you explain what the motivation would be of keeping the translations in a db? Keep in mind that even if we're fetching the translations from a db, they'll still need to be fetched in bulk then compiled+cached.

Or let me turn the question around: what part don't you like about, say, just using XLIFF for translators and then converting to/from a single Tower dictionary.

WIll keep mulling it over, but definitely happy to get your input if you have any! Cheers :-)

m0smith commented 10 years ago

Yes, I see what you are saying now.  I have not used XLIFF before so maybe I am trying to fix something that is not broken.  If I decide I really need the functionality of the ResourceBundles, I could use them directly.

Consider the issue closed.   I am, very sincerely and truly, your Friend and Well-Wisher,

Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com

From: Peter Taoussanis notifications@github.com To: ptaoussanis/tower tower@noreply.github.com Cc: Matthew O. Smith m0smith@yahoo.com Sent: Wednesday, September 25, 2013 12:05 PM Subject: Re: [tower] Using standard Resouce Bundles as dictionaries (#33)

Also, since different people will be doing the translations, it would be good to have separate files to make this more manageable. Hmm, okay - quick thoughts on this:

  1. In most production environments I believe folks will probably be using proper translator tools and file formats. In these cases the .clj dictionary is really an implementation detail to export/import to/from. Is there a particular reason you would want translators to be working directly with the .clj dictionary?
  2. Since the .clj dictionary is just a Clojure file, we do have the ability to use whitespace and/or comments to organize the file structure. In my particular use cases, that's been quite sufficient for relatively small dictionaries (~ few hundred entries by < dozen langs). Am not against the idea, just playing devil's advocate. The change to API would be to change :dictionary to take any function rather than a map. That's an interesting idea which I hadn't thought of. So do I understand correctly that you're proposing we support 3 forms of :dictionary value?:
    1. A map.
    2. A resource name string pointing to a .clj file that reads to a map.
    3. An arbitrary nullary fn that should return a map. Another idea might be a vector of resource names (as in #2) to auto merge. If you don't mind I could take a stab at it. I'm hesitating a little atm since I'm not 100% convinced yet that the extra complication would be a real win in most cases (that is over just exporting/importing to/from traditional translating formats where we'd get a lot of ancillary benefits like translation diffs and inheritance)... Could you explain what the motivation would be of keeping the translations in a db? Keep in mind that even if we're fetching the translations from a db, they'll still need to be fetched in bulk then compiled+cached. Or let me turn the question around: what part don't you like about, say, just using XLIFF for translators and then converting to/from a single Tower dictionary. WIll keep mulling it over, but definitely happy to get your input if you have any! Cheers :-) — Reply to this email directly or view it on GitHub.
ptaoussanis commented 10 years ago

[...] so maybe I am trying to fix something that is not broken

Not necessarily, think it depends on your use case. Note that there isn't a built-in XLIFF converter yet since I haven't had a need for one yet personally, but the spec looks quite simple (it's just XML): http://en.wikipedia.org/wiki/Xliff

You're welcome to take a stab at that if you like: https://github.com/ptaoussanis/tower/issues/30

If I decide I really need the functionality of the ResourceBundles, I could use them directly.

That's definitely an option but I've never been fond of the Java translation facilities myself - usually try avoid them :-)

Anyway, yeah - I'd say take a look at XLIFF (or some other well-known format) and try jigger a simple translator to/from the .clj dictionary format. If you do run into any problems with that approach, let me know and we can talk it out some more. Definitely haven't ruled anything out.

Good luck, cheers! :-)

ptaoussanis commented 10 years ago

I would like to separate out the dictionary for each locale into a separate file

Hi Matthew, quick update: v2.0.0-RC2 (just pushed) includes a facility for doing this: see the example-tconfig for details.

Cheers! :-)