[deepamehta-devel] Translations DM-style

[Malte Reissig]

Hi dear Juergen,

regarding your request I just sent you a reply off-list.

Big up to all contributors &  congratulations for your launch of the TAZ 
project website built with DeepaMehta 4!

Cheers!


On 15.12.2016 12:03, Juergen Neumann wrote:
> Hi Malte,
>
> I totally agree (and recently face!) that the way we provide the
> language issue in the gamechangers project puts a high demand on the
> editors. Wouldn't you want to write a small multi-laguage plugin on the
> poperties level as you are suggesting it, as I think we will really
> need it on the longer term. It's also a demand for the TAZ project, so
> time is a bit crucial here. :)
>
> Waht do you say?
>
> Thx,
>
> JuergeN
>
> PS: The TAZ project is about to be launched in German today:
> https://migration-control.taz.de . Translation is next in the comming
> weeks.
>
> Am Mittwoch, den 14.12.2016, 16:05 +0100 schrieb 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/mai
>>>> n/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.