[deepamehta-devel] Translations DM-style

[Malte Reissig]

Hi Robert,

sorry for adding to the confusion.

Let me try to clarify things a bit.


On 14.12.2016 14:19, Robert Schuster wrote:
> 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.
I did not suggest so. On the contrary, i said, i find jri's proposal 
implemeting multi-lingual topic values using properties a good approach. 
And he explicitly stated that this could be done in a third party 
plugin, not by the core.
> 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
Ok. a) should not make any problems as long as the datasource you import 
carries information/metadata about the language used.

b) Is what i thought. Nonetheless you plan to rely on the editorial 
functionality of the dm4-webclient. The only advice i would have then: 
Plan for training the editors.
>> 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.
Yes, of course. This solely depends on the capabilities of the service 
serving you the resource.
>>> 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.
Why should it not be possible to integrate this "property" approach 
seamlessly into the dm4-webclient editor? The dm4-webclient expects and 
only operates on the "value" field. I think you can succeed to manage 
that in that field only (a) the value for the currently set language 
gets sent over the wire (using preSent server side) and (b) write the 
newly edited/changed value back to the corresponding "value_de-DE" field 
(using postUpdate).

Similar to what you did with mirroring the time-index properties (if i 
understood that right.

I think it should be possible to realize this in a third party plugin 
completely transparent to the user and with the dm4-webclient as editor. 
You would only need to (a) install/provide a language switch to the user 
and (b) alter the AJAX HTTP Headers sent from the dm4-webclient to 
control which language is transferred in the standard "value" field.
> We'd be required to provide
> something external, right? We're actually discussing this in one of the
> projects.
>
Yeah, writing yet anotoher editor, of course, is much more work.
>>> 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
>
As you like. I was just suggesting to abstract the "language specifiers" 
value topics (simply a migration) into an extra plugin.