[deepamehta-devel] Translations DM-style

[Robert Schuster]

Hi Malte,
thanks for the answers so far.

I agree that having language support at the core (in other words,
Deepamehta's core) would be perfect. However we need to provide the
language support in a project and time is a precious resource.


On 14.12.2016 12:06, Malte Reissig wrote:
> The best answer for you is probably related on how the multi-lingual
> data will enter DM. Do you plan to get your data in (1)
> programmability, through importers or a migration or (2) through users
> using (2.1) the dm4-webclient or (2.2) a custom editor developed
> within your project.
Coincidentally I am confronted with both:
a) data is imported through custom import routines that map tabular data
to DM topic (the goal is that the imported data can be maintained by
humans, so the import is handling the data with care)

b) data is entered by a team of editors who are kind of new to DM

>
> On 13.12.2016 09:05, Robert Schuster wrote: 
> - links to external resources that need to be provided in translated
>> form, e.g. a link to the English variant of an article)
> Wouldn't the right way to do this specify a HTTP "Accept-Language"
> Header on the web resource request?
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> Using a "RFC5646" on Language Tag as a value:
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.10
> Otherwise, yes, in this case it is probably best to introduce a custom
> association type using language specifiers.
Probably, but this needs to be supported by the servers hosting the
external documents. AFAIK this is not done. So I don't have control over
this.

>
>> Has anyone done something similar and can share the approach?
> You can find a multi-lingual topic type definition here:
> https://github.com/mukil/dm4-wikidata-toolkit/blob/master/src/main/resources/migrations/migration3.json
>
Ok, I'll study this approach.

>>
>> Is there already consensus about this?
> I think jri's proposal sounds clean and is probably the best way
> considering our current storage layer (see jri's posting). Though I
> currently can not oversee how this might be affected by the recently
> discussed change for an upcoming dm version regarding "Identity and
> Value" types. With that meta-model i think we might all look
> differently onto the problems described in your case.
>
My Problem with the property approach is that it is not possible to edit
the translation with DM's webclient. We'd be required to provide
something external, right? We're actually discussing this in one of the
projects.

>>
>> What I am having in mind is introducing a custom association
>> "translation" which hosts a language specifier and which I then
>> associate manually with all the data that is translated.
>
> We probably all need/want these "language specifiers" represented by
> "Topics" to easily provide users interface elements which allow them
> to interactively switch and select a specific language in our
> webclient (through a human readable name).
>
> Therefore i would be very happy if we as plugin developers could a
> agree on creating a new e.g. "dm4-language-codes" plugin introducing
> just these once and for all. I think it is vital for a growin set of
> plugins that we can rely on the very same language specifiers across
> applications/projects.
I think I am going to implement in the context of the project first,
gain some experience and then make it available through a plug-in if the
approach looks feasible.

All the best,
Robert

-- 
Robert Schuster
freiberuflicher Softwareingenieur

RS01 - IT-Systemanalyse und -entwicklung Robert Schuster
Brückenstraße 4 • 12439 Berlin
+49 157 798 00 310
robert.schuster.rs01 at gmail.com