[deepamehta-devel] Translations DM-style

Juergen Neumann j.neumann at junes.eu
Thu Dec 15 12:03:01 CET 2016


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
>> 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.
-- 
GnuPG KeyID: CD914C6C
Fingerprint: C1CC EF1D 1443 7279 72E7 ABDC A2DA 0328 CD91 4C6C



More information about the devel mailing list