[ckan-dev] Translation issues

[Sean Hammond]

On 10/08/12 09:35, Toby Dacre wrote:
> On 9 August 2012 20:18, Sean Hammond <sean.hammond at okfn.org
> <mailto:sean.hammond at okfn.org>> wrote:
>
> 1) Translating on the fly
>
> We allow people to edit text such as the about page - this should be
> translated or at least have a version for each language - this is
> already broken if ckan.site_about config is used.  Where would be
> the place to keep this? How would it be accessed - maybe we just have
> a different version that can be administered when the language is
> selected - this would be fairly easy as far as the system config is
> concerned.
>
> 2) Translating Field Titles
>
> In resource view page we have additional fields these should be
> translated - some we know some are user defined - We probably want
> the know ones translated as normal but how about the custom ones? -
> This feels it would need a custom system to administer
>
>
> The multilingual extension in core could be extended to translate
> these fields, it currently translates things like dataset and group
> titles and other metadata fields, tags, etc. Seems sensible at first
> glance.
>
> I wonder if the multilingual extension could handle things like the
> about text as well.
>
> Sean,
>
> Thanks,
>
> Do you know where the translations are actually done?  I see we are
> using term_translation_table to hold the values but I can't see where
>  they get set apart from via the api

API is the only way to insert values

> It does look as though it is a sensible place as we are already using
>  this I'm assuming - we may need to make it slightly more flexible -
>  currently we have set languages defined. I appreciate the need for
> the stop words etc.
>
> Are you the best person to liaise with about this

It looks like the fixed list of languages is only involved in 
search/indexing. Kindly wrote that part of the code. Maybe the fixed 
list of languages should become a config option?

I'm not quite sure at first glance what we'll need to do to get it to 
translate these resource fields. Currently the MultilingualDataset 
plugin takes the data dict, flattens it, translates every field, then 
unflattens it (happens when before_view() calls translate_data_dict()). 
So presumably if these resource fields were already in the package dict 
they would already be getting translated. Maybe they are. Or maybe we 
don't have access to the resource dicts at this point. Would have to 
investigate.

Sure I can liaise with you about this, kindly designed this feature, I 
did some of the implementation