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. -- GnuPG KeyID: CD914C6C Fingerprint: C1CC EF1D 1443 7279 72E7 ABDC A2DA 0328 CD91 4C6C -- devel mailing list [email protected] http://lists.deepamehta.de/mailman/listinfo/devel-lists.deepamehta.de
