[ckan-dev] Translation issues

Fri Aug 10 09:20:46 UTC 2012

On 10 August 2012 10:08, Sean Hammond <sean.hammond at okfn.org> wrote:

> 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?
>

Or we could get ckan to provide the list of languages it is using (via
config options, ec-portals auto-detect languages etc)

>
> 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.
>

That is useful and seems quite painless once it's setup, my only worry
would be about things like datetimes etc but there is some logic around
this but it looks like it is fixed key names - not sure how we deal with
dates in custom fields but that's not an issue for now - maybe regexs would
be good enough.

What I really want is to be able to translate field names for custom fields
and things like that.  As we are not wanting the keys of the dicts
translating this will have to be done separately  some sort of ckan _
helper function I'd imagine.  But could definitely share the basic
implementation.

Maybe @kindly has some input

Anyway this is something that I'm still pondering so any implementation
won't start for a few weeks

Cheers

>
> Sure I can liaise with you about this, kindly designed this feature, I did
> some of the implementation
>
>
> ______________________________**_________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/**listinfo/ckan-dev<http://lists.okfn.org/mailman/listinfo/ckan-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120810/e5db5c7a/attachment-0001.html>