Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Dear All,

I have compiled a preliminary set of guidelines to adapting Arches for 
fully multilingual support. You will find this document 
here: 
https://github.com/azerbini/eamena2/blob/master/Making%20Arches%20Multilingual.pdf

Please do let me know your thoughts/doubts/problems.

Best,

Andrea

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Arches] Re: Accessing languages via Django

[Alexei Peters]

That's wonderful!  Glad I could help.


Director of Web Development - Farallon Geographics, Inc. - 971.227.3173

On Tue, Jul 12, 2016 at 8:08 AM,  wrote:

> Alexei,
>
> Thank you for this. Indeed, it led me to solving the problem. I will now
> prepare a short how-to guide to making Arches multilingual, with
> screenshots, and will make it available on this thread.
>
> On Monday, July 11, 2016 at 7:38:50 PM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> I'm still unsure when this is happening, but I'm going to take a stab at
>> this anyway!  :)
>>
>> I'm making this assumption, that the dropdowns (eg 
>> SITE_FUNCTION_CERTAINTY_TYPE.E55)
>> are being populated only with the concepts in the selected language.  That
>> is if I've set the site to display everything in English, then the
>> dropdowns are only displaying the English preflabels.
>>
>> If that's the case, then when you say from your email of July 4th
>>
>>>  It would appear that the problem lies with the viewModel not correctly
>>> picking up the labels when the language selected is not the one with which
>>> the branches were originally saved.
>>
>> that you are correct.
>>
>> You go on to say:
>>
>>> This branch had been added, originally, in English, but the labels
>>> passed by the "load" method have been altered to adhere to the selected
>>> language (Arabic).
>>
>>
>> I think this is the problem.  The dropdowns reference value id's (eg:
>> d30fef92-728b-46f6-a4c5-b42e552a0326 and 
>> 92c37d46-dc23-4869-b868-b978d9f972aa)
>> and not concept ids.  It could be that those value ids in your data
>>
>>
>>> {"nodes":[{"value":"d30fef92-728b-46f6-a4c5-b42e552a0326","label":"عالي","child_entities":[],"entitytypeid":"SITE_FUNCTION_CERTAINTY_TYPE.E55","parentid":"679aa456-943d-4b2d-8c25-947c1f635307","entityid":"86e23739-93f0-40d4-8793-d1dc5043a4f9","property":"P2","businesstablename":"domains"},{"value":"92c37d46-dc23-4869-b868-b978d9f972aa","label":"ديني","child_entities":[],"entitytypeid":"SITE_FUNCTION_TYPE.E55","parentid":"6b8526b0-62ec-4860-9bee-ddf6830d3ff8","entityid":"679aa456-943d-4b2d-8c25-947c1f635307","property":"P2","businesstablename":"domains"}]}
>>
>>
>> don't reference id's in the dropdowns.  I would then expect that when you
>> click to edit a branch that the value referenced in the data can't be found
>> in the dropdowns options and the write method get's a blank value (I've
>> actually confirmed this happens).
>>
>> There's also a file called js/plugins/knockout-select2.js that has an
>> "update" method that you might be interested in.  It's one of the first
>> things that gets called when a user clicks to edit a value that's attached
>> to a dropdown.
>>
>> Hopefully this helps.
>> -Alexei
>>
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Thu, Jul 7, 2016 at 5:30 AM,  wrote:
>>
>>> And here is a screenshot of my debugging of branch-list.js. As you can
>>> see, in the writeable observable, the read correctly maps the valueid of
>>> the concept 'Not Applicable', which is stored in ret. However, the 'write'
>>> callback does not obtain ret, and the argument 'value' is therefore void.
>>>
>>>
>>> 
>>>
>>>
>>>
>>> On Wednesday, July 6, 2016 at 5:34:59 PM UTC+1, zerbini...@gmail.com
>>> wrote:
>>>
 Alexei,

 I have narrowed it down a bit further. The writable computed observable
 that is returned by getEditedNode correctly reads the values retrieved by
 the method getEditedBranch(), but then, if the concept is in Arabic, it
 does not pass it to the "write" callback, despite the variable 'ret' (which
 is returned by the 'read' method in the observable) correctly storing the
 value of the Arabic concept. 'ret', in this case, is essentially not passed
 to the 'write' callback. However, if I add a new branch when the platform
 language is Arabic, save the form and then edit it, all works fine: 'read'
 passes ret to the object 'value' of the 'write' callback and no problem
 arises. I don't understand why the problem is occurring, but I am certain
 that it happens at the juncture between read and write in getEditedNode.


 Andrea

 On Monday, July 4, 2016 at 7:38:19 PM UTC+1, zerbini...@gmail.com
 wrote:

> Hi Alexei,
>
> I have been debugging branch-list.js, and particularly the method
> getEditedNode. It would appear that the problem lies with the viewModel 
> not
> correctly picking up the labels when the language selected is not the one
> with which the branches were originally saved.
> The form data is correctly passed by forms.py with labels in the
> selected language. So, a console log this.data[this.dataKey].branch_lists
> of  on the nodes 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Alexei,

Thank you for this. Indeed, it led me to solving the problem. I will now 
prepare a short how-to guide to making Arches multilingual, with 
screenshots, and will make it available on this thread.

On Monday, July 11, 2016 at 7:38:50 PM UTC+1, Alexei Peters wrote:
>
> Hi Andrea,
> I'm still unsure when this is happening, but I'm going to take a stab at 
> this anyway!  :)
>
> I'm making this assumption, that the dropdowns (eg 
> SITE_FUNCTION_CERTAINTY_TYPE.E55) 
> are being populated only with the concepts in the selected language.  That 
> is if I've set the site to display everything in English, then the 
> dropdowns are only displaying the English preflabels.
>
> If that's the case, then when you say from your email of July 4th
>
>>  It would appear that the problem lies with the viewModel not correctly 
>> picking up the labels when the language selected is not the one with which 
>> the branches were originally saved.
>
> that you are correct. 
>
> You go on to say:
>
>> This branch had been added, originally, in English, but the labels passed 
>> by the "load" method have been altered to adhere to the selected language 
>> (Arabic).
>
>
> I think this is the problem.  The dropdowns reference value id's (eg: 
> d30fef92-728b-46f6-a4c5-b42e552a0326 and 
> 92c37d46-dc23-4869-b868-b978d9f972aa) 
> and not concept ids.  It could be that those value ids in your data
>
>
>> {"nodes":[{"value":"d30fef92-728b-46f6-a4c5-b42e552a0326","label":"عالي","child_entities":[],"entitytypeid":"SITE_FUNCTION_CERTAINTY_TYPE.E55","parentid":"679aa456-943d-4b2d-8c25-947c1f635307","entityid":"86e23739-93f0-40d4-8793-d1dc5043a4f9","property":"P2","businesstablename":"domains"},{"value":"92c37d46-dc23-4869-b868-b978d9f972aa","label":"ديني","child_entities":[],"entitytypeid":"SITE_FUNCTION_TYPE.E55","parentid":"6b8526b0-62ec-4860-9bee-ddf6830d3ff8","entityid":"679aa456-943d-4b2d-8c25-947c1f635307","property":"P2","businesstablename":"domains"}]}
>
>
> don't reference id's in the dropdowns.  I would then expect that when you 
> click to edit a branch that the value referenced in the data can't be found 
> in the dropdowns options and the write method get's a blank value (I've 
> actually confirmed this happens).
>
> There's also a file called js/plugins/knockout-select2.js that has an 
> "update" method that you might be interested in.  It's one of the first 
> things that gets called when a user clicks to edit a value that's attached 
> to a dropdown.
>
> Hopefully this helps.
> -Alexei
>
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Thu, Jul 7, 2016 at 5:30 AM,  
> wrote:
>
>> And here is a screenshot of my debugging of branch-list.js. As you can 
>> see, in the writeable observable, the read correctly maps the valueid of 
>> the concept 'Not Applicable', which is stored in ret. However, the 'write' 
>> callback does not obtain ret, and the argument 'value' is therefore void.
>>
>>
>> 
>>
>>
>>
>> On Wednesday, July 6, 2016 at 5:34:59 PM UTC+1, zerbini...@gmail.com 
>> wrote:
>>
>>> Alexei,
>>>
>>> I have narrowed it down a bit further. The writable computed observable 
>>> that is returned by getEditedNode correctly reads the values retrieved by 
>>> the method getEditedBranch(), but then, if the concept is in Arabic, it 
>>> does not pass it to the "write" callback, despite the variable 'ret' (which 
>>> is returned by the 'read' method in the observable) correctly storing the 
>>> value of the Arabic concept. 'ret', in this case, is essentially not passed 
>>> to the 'write' callback. However, if I add a new branch when the platform 
>>> language is Arabic, save the form and then edit it, all works fine: 'read' 
>>> passes ret to the object 'value' of the 'write' callback and no problem 
>>> arises. I don't understand why the problem is occurring, but I am certain 
>>> that it happens at the juncture between read and write in getEditedNode. 
>>>
>>>
>>> Andrea
>>>
>>> On Monday, July 4, 2016 at 7:38:19 PM UTC+1, zerbini...@gmail.com wrote:
>>>
 Hi Alexei,

 I have been debugging branch-list.js, and particularly the method 
 getEditedNode. It would appear that the problem lies with the viewModel 
 not 
 correctly picking up the labels when the language selected is not the one 
 with which the branches were originally saved.
 The form data is correctly passed by forms.py with labels in the 
 selected language. So, a console log this.data[this.dataKey].branch_lists 
 of  on the nodes SITE_FUNCTION_CERTAINTY_TYPE and SITE_FUNCTION_CERTAINTY 
 returns this: