Re: [Arches] Re: Accessing languages via Django

[Adam Cox]

Hi Andrea, looks like the link to your documentation from this effort 
doesn't work anymore. Would you be able to make it available again?

I'm not sure how much of it will be applicable to v4, but it may be worth 
including in the wiki documentation.

Thanks!
Adam

On Tuesday, July 12, 2016 at 8:05:56 PM UTC+2, zerbini...@gmail.com wrote:
>
> Dear All,
>
> *UPDATE (Aug 2016): *I have further modified get_e55_nodes() to support 
> mixed-language concept labels. See the revised documentation here: 
> https://github.com/azerbini/eamena2/blob/master/Multilingual%20Support%20V2.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

[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:


 

Re: [Arches] Re: Accessing languages via Django

[Alexei Peters]

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:
>>>
>>>
>>> {"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"}]}
>>>
>>>
>>> This branch had been added, originally, in English, but the 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

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:
>
>
> {"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"}]}
>
>
> 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). However, when debugging getEditedNode, this function correctly 
> reads the values of the two selected concepts 
> (d30fef92-728b-46f6-a4c5-b42e552a0326 and 
> 92c37d46-dc23-4869-b868-b978d9f972aa) BUT, for whatever reason, passes an 
> empty object to the write method within getEditedNode.
>
> Can you think of any reason why this might be happening?
>
> Andrea
>
> On Tuesday, June 28, 2016 at 12:20:21 AM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> Have you confirmed that you're getting all the data in all languages when 
>> a form loads, but that somehow the client side code is filtering based on 
>> language?  
>> The "load" method in forms.py would potentially allow a user to only load 
>> data with a specific language code, you're code isn't doing that is it?
>> Cheers,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Fri, Jun 17, 2016 at 8:26 AM,  wrote:
>>
>>> Dear Alexei,
>>>
>>> I have got it to work: 
>>> https://github.com/azerbini/eamena2/blob/app/models/forms.py 
>>>
>>> I was modifying the wrong method, in entity.py instead of looking into 
>>> app/models/forms and changing that get_nodes. My bad.
>>>
>>> Now, the problem is that, for whatever reason (and unrelated to my 
>>> changes to get_nodes()), the JS libraries only allow me to edit branches in 
>>> the language of original insertion. So, when the selected language is 
>>> English, I am able to pull up and edit in a form all of the branches that 
>>> were initially saved in the DB in English. Viceversa, when the language 
>>> selected is Arabic, I can only edit branches (or entities - call them as 
>>> you may) that were saved into the DB in Arabic. Any idea as to why the JS 
>>> does this? 
>>>
>>> Thank you - getting there step by step!
>>>
>>> Andrea
>>>
>>> On Thursday, June 16, 2016 at 7:43:59 PM UTC+1, Alexei Peters wrote:

 Hi Andrea,
 I'll have to look into this.
 Cheers,
 Alexei


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

 On Wed, Jun 15, 2016 at 10:43 AM,  wrote:

> A small update. I have been able to bypass the indexing problem by 
> commenting off lines 228-30 in app/search/search.py and replacing the 
> custom exception with a standard return False.
> I subsequently modified get_nodes() as visible here: 
> https://github.com/azerbini/eamena2/blob/app/models/entity.py
>
> Now, the labels returned by get_nodes are in the correct language, and 
> yet they keep being visualised in the templates in the language of 
> original 
> insertion (see screenshot attached). Once again, what do I need to modify 
> in order to tweak the resource graph which is passed as an observable 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

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:

{"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"}]}


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). However, when debugging getEditedNode, this function correctly 
reads the values of the two selected concepts 
(d30fef92-728b-46f6-a4c5-b42e552a0326 and 
92c37d46-dc23-4869-b868-b978d9f972aa) BUT, for whatever reason, passes an 
empty object to the write method within getEditedNode.

Can you think of any reason why this might be happening?

Andrea

On Tuesday, June 28, 2016 at 12:20:21 AM UTC+1, Alexei Peters wrote:
>
> Hi Andrea,
> Have you confirmed that you're getting all the data in all languages when 
> a form loads, but that somehow the client side code is filtering based on 
> language?  
> The "load" method in forms.py would potentially allow a user to only load 
> data with a specific language code, you're code isn't doing that is it?
> Cheers,
> Alexei
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Fri, Jun 17, 2016 at 8:26 AM,  
> wrote:
>
>> Dear Alexei,
>>
>> I have got it to work: 
>> https://github.com/azerbini/eamena2/blob/app/models/forms.py 
>>
>> I was modifying the wrong method, in entity.py instead of looking into 
>> app/models/forms and changing that get_nodes. My bad.
>>
>> Now, the problem is that, for whatever reason (and unrelated to my 
>> changes to get_nodes()), the JS libraries only allow me to edit branches in 
>> the language of original insertion. So, when the selected language is 
>> English, I am able to pull up and edit in a form all of the branches that 
>> were initially saved in the DB in English. Viceversa, when the language 
>> selected is Arabic, I can only edit branches (or entities - call them as 
>> you may) that were saved into the DB in Arabic. Any idea as to why the JS 
>> does this? 
>>
>> Thank you - getting there step by step!
>>
>> Andrea
>>
>> On Thursday, June 16, 2016 at 7:43:59 PM UTC+1, Alexei Peters wrote:
>>>
>>> Hi Andrea,
>>> I'll have to look into this.
>>> Cheers,
>>> Alexei
>>>
>>>
>>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>>
>>> On Wed, Jun 15, 2016 at 10:43 AM,  wrote:
>>>
 A small update. I have been able to bypass the indexing problem by 
 commenting off lines 228-30 in app/search/search.py and replacing the 
 custom exception with a standard return False.
 I subsequently modified get_nodes() as visible here: 
 https://github.com/azerbini/eamena2/blob/app/models/entity.py

 Now, the labels returned by get_nodes are in the correct language, and 
 yet they keep being visualised in the templates in the language of 
 original 
 insertion (see screenshot attached). Once again, what do I need to modify 
 in order to tweak the resource graph which is passed as an observable 
 array 
 to branch-list.js? 

 Thanks,

 andrea


 



 On Wednesday, June 15, 2016 at 2:23:53 PM UTC+1, zerbini...@gmail.com 
 wrote:
>
> Hi all,
>
> In order to fix the visualisation of the already selected branches, I 
> have tried to modify models/entity.py, particularly the get_nodes method, 
> since it is that which calls the labels of concepts already stored in the 
> database (see here for the modified method: 
> https://github.com/azerbini/eamena2/blob/app/models/entity.py). 
> Currently, I am only trying to get get_nodes() to retrieve the right 
> prefLabels, so I am not modifying the data, just displaying it via print 
> statements. I have had to perform a UUID validation of entity.value in 
> order to stop get_preflabels_from_valueid 

Re: [Arches] Re: Accessing languages via Django

['Lucy Fletcher-Jones' via Arches Project]

Hi Andrea,

Thank you very much and thank you for sharing everything. I am sorry we cannot 
help you on this as we are currently engaged on other customisations and have a 
long summer break now. We will likely start looking at this in October. 

Best wishes to Michael Fradley and the rest of the team. 

Lucy


  - Original Message - 
  From: zerbini.eam...@gmail.com 
  To: Arches Project 
  Sent: Tuesday, June 28, 2016 12:53 AM
  Subject: Re: [Arches] Re: Accessing languages via Django


  Hi Lucy, I am doing just that these days. However, I still miss one critical 
step, that concerning to editing branches (see my last question for Alexei 
above). I have managed to introduce a second language in the Languages 
selection menu in the header, add multilanguage support in the E55 dropdowns 
and in the visualisation of selected branches. The last hurdle is that which 
concerns editing branches. Currently, when I select a branch for editing, this 
will populate the form fields only if the branch was saved in the language 
currently being displayed. So, for example, if I am currently visualising my 
platform in Arabic, I will only be able to edit branches that were added,and 
saved, in Arabic. This is strange as the JSON resource graph read by the KO 
libraries contains the labels in the correct language. I am still debugging 
this. When I finally manage to get this done, I will compile a set of 
guidelines to setting up multilingual support.


  Andrea

  On Sunday, June 26, 2016 at 1:21:11 PM UTC+2, Lucy FJ wrote:
Dear Andrea, Adam, Alexei et al,


We, the Egyptian Archaeological Database project team, will also be 
implementing an Arabic versdion of our Arches iteration. I have followed this 
technical discussion but it still  isn't totally clear how to install a second 
language in Arches. I know everyone is very busy, but we would be eternally 
grateful (this means a lot to Egyptologists!!) if one of you could write a 
short document outlining the technical steps necessary to install a second 
language in Arches. Are there any particular problems associated with Arabic 
being a second language? Cheers and thank you very much indeed! 


Lucy
   

On Friday, June 17, 2016 at 5:26:52 PM UTC+2, zerbini...@gmail.com wrote:
  Dear Alexei,


  I have got it to work: 
https://github.com/azerbini/eamena2/blob/app/models/forms.py 


  I was modifying the wrong method, in entity.py instead of looking into 
app/models/forms and changing that get_nodes. My bad.


  Now, the problem is that, for whatever reason (and unrelated to my 
changes to get_nodes()), the JS libraries only allow me to edit branches in the 
language of original insertion. So, when the selected language is English, I am 
able to pull up and edit in a form all of the branches that were initially 
saved in the DB in English. Viceversa, when the language selected is Arabic, I 
can only edit branches (or entities - call them as you may) that were saved 
into the DB in Arabic. Any idea as to why the JS does this? 


  Thank you - getting there step by step!


  Andrea

  On Thursday, June 16, 2016 at 7:43:59 PM UTC+1, Alexei Peters wrote:
Hi Andrea,
I'll have to look into this.
Cheers,
Alexei




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



On Wed, Jun 15, 2016 at 10:43 AM, <zerbini...@gmail.com> wrote:

  A small update. I have been able to bypass the indexing problem by 
commenting off lines 228-30 in app/search/search.py and replacing the custom 
exception with a standard return False.
  I subsequently modified get_nodes() as visible here: 
https://github.com/azerbini/eamena2/blob/app/models/entity.py


  Now, the labels returned by get_nodes are in the correct language, 
and yet they keep being visualised in the templates in the language of original 
insertion (see screenshot attached). Once again, what do I need to modify in 
order to tweak the resource graph which is passed as an observable array to 
branch-list.js? 


  Thanks,


  andrea









  On Wednesday, June 15, 2016 at 2:23:53 PM UTC+1, zerbini...@gmail.com 
wrote:
Hi all,


In order to fix the visualisation of the already selected branches, 
I have tried to modify models/entity.py, particularly the get_nodes method, 
since it is that which calls the labels of concepts already stored in the 
database (see here for the modified method: 
https://github.com/azerbini/eamena2/blob/app/models/entity.py). Currently, I am 
only trying to get get_nodes() to retrieve the right prefLabels, so I am not 
modifying the data, just displaying it via print statements. I have had to 
perform a UUID validation of entity.value in order to stop 
get_preflabels_from_valueid from attempting to run on entity.value when the 
latter is a Polygon type. When I modify a form, on POST submission, all

Re: [Arches] Re: Accessing languages via Django

[Alexei Peters]

Hi Andrea,
Have you confirmed that you're getting all the data in all languages when a
form loads, but that somehow the client side code is filtering based on
language?
The "load" method in forms.py would potentially allow a user to only load
data with a specific language code, you're code isn't doing that is it?
Cheers,
Alexei


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

On Fri, Jun 17, 2016 at 8:26 AM,  wrote:

> Dear Alexei,
>
> I have got it to work:
> https://github.com/azerbini/eamena2/blob/app/models/forms.py
>
> I was modifying the wrong method, in entity.py instead of looking into
> app/models/forms and changing that get_nodes. My bad.
>
> Now, the problem is that, for whatever reason (and unrelated to my changes
> to get_nodes()), the JS libraries only allow me to edit branches in the
> language of original insertion. So, when the selected language is English,
> I am able to pull up and edit in a form all of the branches that were
> initially saved in the DB in English. Viceversa, when the language selected
> is Arabic, I can only edit branches (or entities - call them as you may)
> that were saved into the DB in Arabic. Any idea as to why the JS does this?
>
> Thank you - getting there step by step!
>
> Andrea
>
> On Thursday, June 16, 2016 at 7:43:59 PM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> I'll have to look into this.
>> Cheers,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Wed, Jun 15, 2016 at 10:43 AM,  wrote:
>>
>>> A small update. I have been able to bypass the indexing problem by
>>> commenting off lines 228-30 in app/search/search.py and replacing the
>>> custom exception with a standard return False.
>>> I subsequently modified get_nodes() as visible here:
>>> https://github.com/azerbini/eamena2/blob/app/models/entity.py
>>>
>>> Now, the labels returned by get_nodes are in the correct language, and
>>> yet they keep being visualised in the templates in the language of original
>>> insertion (see screenshot attached). Once again, what do I need to modify
>>> in order to tweak the resource graph which is passed as an observable array
>>> to branch-list.js?
>>>
>>> Thanks,
>>>
>>> andrea
>>>
>>>
>>> 
>>>
>>>
>>>
>>> On Wednesday, June 15, 2016 at 2:23:53 PM UTC+1, zerbini...@gmail.com
>>> wrote:

 Hi all,

 In order to fix the visualisation of the already selected branches, I
 have tried to modify models/entity.py, particularly the get_nodes method,
 since it is that which calls the labels of concepts already stored in the
 database (see here for the modified method:
 https://github.com/azerbini/eamena2/blob/app/models/entity.py).
 Currently, I am only trying to get get_nodes() to retrieve the right
 prefLabels, so I am not modifying the data, just displaying it via print
 statements. I have had to perform a UUID validation of entity.value in
 order to stop get_preflabels_from_valueid from attempting to run on
 entity.value when the latter is a Polygon type. When I modify a form, on
 POST submission, all seems to work fine. Here are some of the outputs I get
 on the server:

 Entity label pre prefLabel: :
> d7f8c3f4-abb5-4d88-879e-41574d905df7 of type
> SITE_OVERALL_ARCHAEOLOGICAL_CERTAINTY_TYPE.E55 with value
> "e2febf75-58b1-4803-a7f9-c7cd3d01606b"
>
> {u'_type': u'1e0f9e9a-99e0-4439-a796-f0e1c9e26db9', u'_source':
> {u'category': u'label', u'conceptid':
> u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'en-US', u'value':
> u'High', u'type': u'prefLabel', u'id':
> u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}, u'_index': u'concept_labels',
> u'_version': 2, u'found': True, u'_id':
> u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}
>
> Entity label post prefLabel: {u'category': u'label', u'conceptid':
> u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'ar', u'value':
> u'\u0639\u0627\u0644\u064a', u'type': u'prefLabel', u'id':
> u'75905a06-9b0e-4c72-84c9-ae6883b83b30'}
>


 As you can see, get_preflabels_from_valueid has correctly located my
 new label value. However, I then get an ES indexing problem:

 RequestError at
> /resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
> TransportError(400, u'MapperParsingException[object mapping for
> [HERITAGE_RESOURCE_GROUP.E27] tried to parse as object, but got EOF, has a
> concrete value been provided to it?]')
> Request Method: POST
> Request URL:
> http://localhost:8000/resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
> Django Version: 1.6.2
> Exception Type: RequestError
> Exception 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Hi Lucy, I am doing just that these days. However, I still miss one 
critical step, that concerning to editing branches (see my last question 
for Alexei above). I have managed to introduce a second language in the 
Languages selection menu in the header, add multilanguage support in the 
E55 dropdowns and in the visualisation of selected branches. The last 
hurdle is that which concerns editing branches. Currently, when I select a 
branch for editing, this will populate the form fields only if the branch 
was saved in the language currently being displayed. So, for example, if I 
am currently visualising my platform in Arabic, I will only be able to edit 
branches that were added,and saved, in Arabic. This is strange as the JSON 
resource graph read by the KO libraries contains the labels in the correct 
language. I am still debugging this. When I finally manage to get this 
done, I will compile a set of guidelines to setting up multilingual support.

Andrea

On Sunday, June 26, 2016 at 1:21:11 PM UTC+2, Lucy FJ wrote:
>
> Dear Andrea, Adam, Alexei et al,
>
> We, the Egyptian Archaeological Database project team, will also be 
> implementing an Arabic versdion of our Arches iteration. I have followed 
> this technical discussion but it still  isn't totally clear how to install 
> a second language in Arches. I know everyone is very busy, but we would be 
> eternally grateful (this means a lot to Egyptologists!!) if one of you 
> could write a short document outlining the technical steps necessary to 
> install a second language in Arches. Are there any particular problems 
> associated with Arabic being a second language? Cheers and thank you very 
> much indeed! 
>
> Lucy
>
>
> On Friday, June 17, 2016 at 5:26:52 PM UTC+2, zerbini...@gmail.com wrote:
>>
>> Dear Alexei,
>>
>> I have got it to work: 
>> https://github.com/azerbini/eamena2/blob/app/models/forms.py 
>>
>> I was modifying the wrong method, in entity.py instead of looking into 
>> app/models/forms and changing that get_nodes. My bad.
>>
>> Now, the problem is that, for whatever reason (and unrelated to my 
>> changes to get_nodes()), the JS libraries only allow me to edit branches in 
>> the language of original insertion. So, when the selected language is 
>> English, I am able to pull up and edit in a form all of the branches that 
>> were initially saved in the DB in English. Viceversa, when the language 
>> selected is Arabic, I can only edit branches (or entities - call them as 
>> you may) that were saved into the DB in Arabic. Any idea as to why the JS 
>> does this? 
>>
>> Thank you - getting there step by step!
>>
>> Andrea
>>
>> On Thursday, June 16, 2016 at 7:43:59 PM UTC+1, Alexei Peters wrote:
>>>
>>> Hi Andrea,
>>> I'll have to look into this.
>>> Cheers,
>>> Alexei
>>>
>>>
>>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>>
>>> On Wed, Jun 15, 2016 at 10:43 AM,  wrote:
>>>
 A small update. I have been able to bypass the indexing problem by 
 commenting off lines 228-30 in app/search/search.py and replacing the 
 custom exception with a standard return False.
 I subsequently modified get_nodes() as visible here: 
 https://github.com/azerbini/eamena2/blob/app/models/entity.py

 Now, the labels returned by get_nodes are in the correct language, and 
 yet they keep being visualised in the templates in the language of 
 original 
 insertion (see screenshot attached). Once again, what do I need to modify 
 in order to tweak the resource graph which is passed as an observable 
 array 
 to branch-list.js? 

 Thanks,

 andrea


 



 On Wednesday, June 15, 2016 at 2:23:53 PM UTC+1, zerbini...@gmail.com 
 wrote:
>
> Hi all,
>
> In order to fix the visualisation of the already selected branches, I 
> have tried to modify models/entity.py, particularly the get_nodes method, 
> since it is that which calls the labels of concepts already stored in the 
> database (see here for the modified method: 
> https://github.com/azerbini/eamena2/blob/app/models/entity.py). 
> Currently, I am only trying to get get_nodes() to retrieve the right 
> prefLabels, so I am not modifying the data, just displaying it via print 
> statements. I have had to perform a UUID validation of entity.value in 
> order to stop get_preflabels_from_valueid from attempting to run on 
> entity.value when the latter is a Polygon type. When I modify a form, on 
> POST submission, all seems to work fine. Here are some of the outputs I 
> get 
> on the server:
>
> Entity label pre prefLabel: : 
>> d7f8c3f4-abb5-4d88-879e-41574d905df7 of type 
>> 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Dear Alexei,

I have got it to 
work: https://github.com/azerbini/eamena2/blob/app/models/forms.py 

I was modifying the wrong method, in entity.py instead of looking into 
app/models/forms and changing that get_nodes. My bad.

Now, the problem is that, for whatever reason (and unrelated to my changes 
to get_nodes()), the JS libraries only allow me to edit branches in the 
language of original insertion. So, when the selected language is English, 
I am able to pull up and edit in a form all of the branches that were 
initially saved in the DB in English. Viceversa, when the language selected 
is Arabic, I can only edit branches (or entities - call them as you may) 
that were saved into the DB in Arabic. Any idea as to why the JS does this? 

Thank you - getting there step by step!

Andrea

On Thursday, June 16, 2016 at 7:43:59 PM UTC+1, Alexei Peters wrote:
>
> Hi Andrea,
> I'll have to look into this.
> Cheers,
> Alexei
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Wed, Jun 15, 2016 at 10:43 AM,  
> wrote:
>
>> A small update. I have been able to bypass the indexing problem by 
>> commenting off lines 228-30 in app/search/search.py and replacing the 
>> custom exception with a standard return False.
>> I subsequently modified get_nodes() as visible here: 
>> https://github.com/azerbini/eamena2/blob/app/models/entity.py
>>
>> Now, the labels returned by get_nodes are in the correct language, and 
>> yet they keep being visualised in the templates in the language of original 
>> insertion (see screenshot attached). Once again, what do I need to modify 
>> in order to tweak the resource graph which is passed as an observable array 
>> to branch-list.js? 
>>
>> Thanks,
>>
>> andrea
>>
>>
>> 
>>
>>
>>
>> On Wednesday, June 15, 2016 at 2:23:53 PM UTC+1, zerbini...@gmail.com 
>> wrote:
>>>
>>> Hi all,
>>>
>>> In order to fix the visualisation of the already selected branches, I 
>>> have tried to modify models/entity.py, particularly the get_nodes method, 
>>> since it is that which calls the labels of concepts already stored in the 
>>> database (see here for the modified method: 
>>> https://github.com/azerbini/eamena2/blob/app/models/entity.py). 
>>> Currently, I am only trying to get get_nodes() to retrieve the right 
>>> prefLabels, so I am not modifying the data, just displaying it via print 
>>> statements. I have had to perform a UUID validation of entity.value in 
>>> order to stop get_preflabels_from_valueid from attempting to run on 
>>> entity.value when the latter is a Polygon type. When I modify a form, on 
>>> POST submission, all seems to work fine. Here are some of the outputs I get 
>>> on the server:
>>>
>>> Entity label pre prefLabel: : 
 d7f8c3f4-abb5-4d88-879e-41574d905df7 of type 
 SITE_OVERALL_ARCHAEOLOGICAL_CERTAINTY_TYPE.E55 with value 
 "e2febf75-58b1-4803-a7f9-c7cd3d01606b"

 {u'_type': u'1e0f9e9a-99e0-4439-a796-f0e1c9e26db9', u'_source': 
 {u'category': u'label', u'conceptid': 
 u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'en-US', u'value': 
 u'High', u'type': u'prefLabel', u'id': 
 u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}, u'_index': u'concept_labels', 
 u'_version': 2, u'found': True, u'_id': 
 u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}

 Entity label post prefLabel: {u'category': u'label', u'conceptid': 
 u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'ar', u'value': 
 u'\u0639\u0627\u0644\u064a', u'type': u'prefLabel', u'id': 
 u'75905a06-9b0e-4c72-84c9-ae6883b83b30'}

>>>
>>>
>>> As you can see, get_preflabels_from_valueid has correctly located my new 
>>> label value. However, I then get an ES indexing problem:
>>>
>>> RequestError at 
 /resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
 TransportError(400, u'MapperParsingException[object mapping for 
 [HERITAGE_RESOURCE_GROUP.E27] tried to parse as object, but got EOF, has a 
 concrete value been provided to it?]')
 Request Method: POST
 Request URL: 
 http://localhost:8000/resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
 Django Version: 1.6.2
 Exception Type: RequestError
 Exception Value: 

 TransportError(400, u'MapperParsingException[object mapping for 
 [HERITAGE_RESOURCE_GROUP.E27] tried to parse as object, but got EOF, has a 
 concrete value been provided to it?]')

 Exception Location: 
 /Users/eamena/Projects/ENV/lib/python2.7/site-packages/arches/app/search/search.py
  
 in index_data, line 227


>>> Why is the indexing called, and when? Why does it fail, considering that 
>>> I have not changed anything at all, just printed to console? 
>>>
>>> Thanks for your 

Re: [Arches] Re: Accessing languages via Django

[Alexei Peters]

Hi Andrea,
I'll have to look into this.
Cheers,
Alexei


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

On Wed, Jun 15, 2016 at 10:43 AM,  wrote:

> A small update. I have been able to bypass the indexing problem by
> commenting off lines 228-30 in app/search/search.py and replacing the
> custom exception with a standard return False.
> I subsequently modified get_nodes() as visible here:
> https://github.com/azerbini/eamena2/blob/app/models/entity.py
>
> Now, the labels returned by get_nodes are in the correct language, and yet
> they keep being visualised in the templates in the language of original
> insertion (see screenshot attached). Once again, what do I need to modify
> in order to tweak the resource graph which is passed as an observable array
> to branch-list.js?
>
> Thanks,
>
> andrea
>
>
> 
>
>
>
> On Wednesday, June 15, 2016 at 2:23:53 PM UTC+1, zerbini...@gmail.com
> wrote:
>>
>> Hi all,
>>
>> In order to fix the visualisation of the already selected branches, I
>> have tried to modify models/entity.py, particularly the get_nodes method,
>> since it is that which calls the labels of concepts already stored in the
>> database (see here for the modified method:
>> https://github.com/azerbini/eamena2/blob/app/models/entity.py).
>> Currently, I am only trying to get get_nodes() to retrieve the right
>> prefLabels, so I am not modifying the data, just displaying it via print
>> statements. I have had to perform a UUID validation of entity.value in
>> order to stop get_preflabels_from_valueid from attempting to run on
>> entity.value when the latter is a Polygon type. When I modify a form, on
>> POST submission, all seems to work fine. Here are some of the outputs I get
>> on the server:
>>
>> Entity label pre prefLabel: :
>>> d7f8c3f4-abb5-4d88-879e-41574d905df7 of type
>>> SITE_OVERALL_ARCHAEOLOGICAL_CERTAINTY_TYPE.E55 with value
>>> "e2febf75-58b1-4803-a7f9-c7cd3d01606b"
>>>
>>> {u'_type': u'1e0f9e9a-99e0-4439-a796-f0e1c9e26db9', u'_source':
>>> {u'category': u'label', u'conceptid':
>>> u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'en-US', u'value':
>>> u'High', u'type': u'prefLabel', u'id':
>>> u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}, u'_index': u'concept_labels',
>>> u'_version': 2, u'found': True, u'_id':
>>> u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}
>>>
>>> Entity label post prefLabel: {u'category': u'label', u'conceptid':
>>> u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'ar', u'value':
>>> u'\u0639\u0627\u0644\u064a', u'type': u'prefLabel', u'id':
>>> u'75905a06-9b0e-4c72-84c9-ae6883b83b30'}
>>>
>>
>>
>> As you can see, get_preflabels_from_valueid has correctly located my new
>> label value. However, I then get an ES indexing problem:
>>
>> RequestError at
>>> /resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
>>> TransportError(400, u'MapperParsingException[object mapping for
>>> [HERITAGE_RESOURCE_GROUP.E27] tried to parse as object, but got EOF, has a
>>> concrete value been provided to it?]')
>>> Request Method: POST
>>> Request URL:
>>> http://localhost:8000/resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
>>> Django Version: 1.6.2
>>> Exception Type: RequestError
>>> Exception Value:
>>>
>>> TransportError(400, u'MapperParsingException[object mapping for 
>>> [HERITAGE_RESOURCE_GROUP.E27] tried to parse as object, but got EOF, has a 
>>> concrete value been provided to it?]')
>>>
>>> Exception Location: 
>>> /Users/eamena/Projects/ENV/lib/python2.7/site-packages/arches/app/search/search.py
>>> in index_data, line 227
>>>
>>>
>> Why is the indexing called, and when? Why does it fail, considering that
>> I have not changed anything at all, just printed to console?
>>
>> Thanks for your help,
>>
>> Andrea
>>
>>
>>
>>
>> On Tuesday, June 14, 2016 at 8:40:32 AM UTC+1, zerbini...@gmail.com
>> wrote:
>>>
>>> All this makes sense Alexei. However, I am still trying to figure out at
>>> which point in concept.py (or other python file) does the get_preflabel get
>>> called when created a resource graph. I am asking this as I am still unable
>>> to see the translated labels in the already selected branches (those, in
>>> other words, that get populated in the templates by branch-list.js).
>>>
>>> Can you help?
>>>
>>> Thanks,
>>>
>>> Andrea
>>>
>>> On Monday, June 13, 2016 at 10:50:37 PM UTC+1, Alexei Peters wrote:

 Hi Andrea,
 Keep in mind that when you see something like this:

 def get_preflabel(self, lang=settings.LANGUAGE_CODE)

 What it means is, use for  "lang" the value defined in
 settings.LANGUAGE_CODE if nothing else is provided.
 Most of the views take in a lang property as part of the request,
 defaulting, again, to settings.LANGUAGE_CODE if none 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Hi all,

In order to fix the visualisation of the already selected branches, I have 
tried to modify models/entity.py, particularly the get_nodes method, since 
it is that which calls the labels of concepts already stored in the 
database (see here for the modifying method: 
https://github.com/azerbini/eamena2/blob/app/models/entity.py). Currently, 
I am only trying to get get_nodes() to retrieve the right prefLabels, so I 
am not modifying the data, just displaying it via print statements. I have 
had to perform a UUID validation of entity.value in order to stop 
get_preflabels_from_valueid from attempting to run on entity.value when the 
latter is a Polygon type. When I modify a form, on POST submission, all 
seems to work fine. Here are some of the outputs I get on the server:

Entity label pre prefLabel: : 
> d7f8c3f4-abb5-4d88-879e-41574d905df7 of type 
> SITE_OVERALL_ARCHAEOLOGICAL_CERTAINTY_TYPE.E55 with value 
> "e2febf75-58b1-4803-a7f9-c7cd3d01606b"
>
> {u'_type': u'1e0f9e9a-99e0-4439-a796-f0e1c9e26db9', u'_source': 
> {u'category': u'label', u'conceptid': 
> u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'en-US', u'value': 
> u'High', u'type': u'prefLabel', u'id': 
> u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}, u'_index': u'concept_labels', 
> u'_version': 2, u'found': True, u'_id': 
> u'e2febf75-58b1-4803-a7f9-c7cd3d01606b'}
>
> Entity label post prefLabel: {u'category': u'label', u'conceptid': 
> u'8748c8c7-8d3d-4003-a6b5-f87d9d933490', u'language': u'ar', u'value': 
> u'\u0639\u0627\u0644\u064a', u'type': u'prefLabel', u'id': 
> u'75905a06-9b0e-4c72-84c9-ae6883b83b30'}
>


As you can see, get_preflabels_from_valueid has correctly located my new 
label value. However, I then get an ES indexing problem:

RequestError at 
> /resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
> TransportError(400, u'MapperParsingException[object mapping for 
> [HERITAGE_RESOURCE_GROUP.E27] tried to parse as object, but got EOF, has a 
> concrete value been provided to it?]')
> Request Method: POST
> Request URL: 
> http://localhost:8000/resources/HERITAGE_RESOURCE_GROUP.E27/summary/8b712dc9-5de2-446f-900e-26a63e511d91
> Django Version: 1.6.2
> Exception Type: RequestError
> Exception Value: 
>
> TransportError(400, u'MapperParsingException[object mapping for 
> [HERITAGE_RESOURCE_GROUP.E27] tried to parse as object, but got EOF, has a 
> concrete value been provided to it?]')
>
> Exception Location: 
> /Users/eamena/Projects/ENV/lib/python2.7/site-packages/arches/app/search/search.py
>  
> in index_data, line 227
>
>
Why is the indexing called, and when? Why does it fail, considering that I 
have not changed anything at all, just printed to console? 

Thanks for your help,

Andrea




On Tuesday, June 14, 2016 at 8:40:32 AM UTC+1, zerbini...@gmail.com wrote:
>
> All this makes sense Alexei. However, I am still trying to figure out at 
> which point in concept.py (or other python file) does the get_preflabel get 
> called when created a resource graph. I am asking this as I am still unable 
> to see the translated labels in the already selected branches (those, in 
> other words, that get populated in the templates by branch-list.js).
>
> Can you help?
>
> Thanks,
>
> Andrea
>
> On Monday, June 13, 2016 at 10:50:37 PM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> Keep in mind that when you see something like this:
>>
>> def get_preflabel(self, lang=settings.LANGUAGE_CODE)
>>
>> What it means is, use for  "lang" the value defined in 
>> settings.LANGUAGE_CODE if nothing else is provided.
>> Most of the views take in a lang property as part of the request, 
>> defaulting, again, to settings.LANGUAGE_CODE if none is provided.
>>
>> eg: in app/views/concept.py on line 74
>> lang = request.GET.get('lang', settings.LANGUAGE_CODE)
>>
>> what this means is that if your request has a "lang" property in the 
>> querystring 
>> eg: 
>> http://blahblahblah/concept/----111?lang=ar
>> then the language code "ar" should be passed on down to the get_preflabel 
>> function with the language passed in from the request and it will not use 
>> the value from settings.LANGUAGE_CODE
>>
>> Hope that helps clarify how that all works.
>> Cheers,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Fri, Jun 10, 2016 at 11:44 AM,  wrote:
>>
>>> In my case Alexei, this wouldn't work as I use the Middleware to operate 
>>> language changes - settings.LANGUAGE_CODE would remain defaulted to en_US 
>>> (the only lang code that I have assigned in settings.py). Instead, I have 
>>> worked around this issue by replacing settings.LANGUAGE_CODE with 
>>> translation.get_language().
>>>
>>> a.
>>>
>>> On Friday, June 10, 2016 at 7:22:20 PM UTC+1, Alexei Peters wrote:

 Hi Andrea,
 There is a method in the models/concept.py file at line 375 called 
 "get_preflabel"

 def get_preflabel(self, 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

All this makes sense Alexei. However, I am still trying to figure out at 
which point in concept.py (or other python file) does the get_preflabel get 
called when created a resource graph. I am asking this as I am still unable 
to see the translated labels in the already selected branches (those, in 
other words, that get populated in the templates by branch-list.js).

Can you help?

Thanks,

Andrea

On Monday, June 13, 2016 at 10:50:37 PM UTC+1, Alexei Peters wrote:
>
> Hi Andrea,
> Keep in mind that when you see something like this:
>
> def get_preflabel(self, lang=settings.LANGUAGE_CODE)
>
> What it means is, use for  "lang" the value defined in 
> settings.LANGUAGE_CODE if nothing else is provided.
> Most of the views take in a lang property as part of the request, 
> defaulting, again, to settings.LANGUAGE_CODE if none is provided.
>
> eg: in app/views/concept.py on line 74
> lang = request.GET.get('lang', settings.LANGUAGE_CODE)
>
> what this means is that if your request has a "lang" property in the 
> querystring 
> eg: 
> http://blahblahblah/concept/----111?lang=ar
> then the language code "ar" should be passed on down to the get_preflabel 
> function with the language passed in from the request and it will not use 
> the value from settings.LANGUAGE_CODE
>
> Hope that helps clarify how that all works.
> Cheers,
> Alexei
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Fri, Jun 10, 2016 at 11:44 AM,  
> wrote:
>
>> In my case Alexei, this wouldn't work as I use the Middleware to operate 
>> language changes - settings.LANGUAGE_CODE would remain defaulted to en_US 
>> (the only lang code that I have assigned in settings.py). Instead, I have 
>> worked around this issue by replacing settings.LANGUAGE_CODE with 
>> translation.get_language().
>>
>> a.
>>
>> On Friday, June 10, 2016 at 7:22:20 PM UTC+1, Alexei Peters wrote:
>>>
>>> Hi Andrea,
>>> There is a method in the models/concept.py file at line 375 called 
>>> "get_preflabel"
>>>
>>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
 ret = []
 if self.values == []: 
 concept = Concept().get(id=self.id, 
 include_subconcepts=False, include_parentconcepts=False, include=['label'])
 else:
 concept = self
 for value in concept.values:
 if value.type == 'prefLabel':
 if value.language == lang:
 return value
 elif value.language == lang.split('-')[0]:
 ret.insert(0, value)
 elif value.type == 'altLabel':
 if value.language == lang:
 ret.insert(0, value)
 ret.append(value)
 return ret[0] if len(ret) > 0 else ConceptValue()
>>>
>>>
>>> that method has been updated in Arches v4 to this:
>>>
>>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
 score = 0
 ranked_labels = []
 if self.values == []:
 concept = Concept().get(id=self.id, 
 include_subconcepts=False, include_parentconcepts=False, include=['label'])
 else:
 concept = self
 for value in concept.values:
 ranked_label = {
 'weight': 1,
 'value': value
 }
 if value.type == 'prefLabel':
 ranked_label['weight'] = ranked_label['weight'] * 10
 elif value.type == 'altLabel':
 ranked_label['weight'] = ranked_label['weight'] * 4
 if value.language == lang:
 ranked_label['weight'] = ranked_label['weight'] * 10
 elif value.language.split('-')[0] == lang.split('-')[0]:
 ranked_label['weight'] = ranked_label['weight'] * 5
 ranked_labels.append(ranked_label)
 ranked_labels = sorted(ranked_labels, key=lambda label: 
 label['weight'], reverse=True)
 if len(ranked_labels) == 0:
 ranked_labels.append({
 'weight': 1,
 'value': ConceptValue()
 })
 return ranked_labels[0]['value'] 
>>>
>>>
>>> as a test, you might try replacing the old method with the new one.
>>> Also like I mentioned before, I would create prefLabels for all your 
>>> Arabic concepts.
>>>
>>> If that fixes the issue, I can update the v3 code accordingly and you 
>>> could then update your package from that.
>>>
>>> Hope that helps.
>>> Cheers,
>>> Alexei
>>>
>>>
>>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>>
>>> On Fri, Jun 10, 2016 at 8:19 AM,  wrote:
>>>
 That's what we had done in the beginning Alexei. However, for some 
 unclear reason, it would appear that Arches selects among 

Re: [Arches] Re: Accessing languages via Django

[Alexei Peters]

Hi Andrea,
Keep in mind that when you see something like this:

def get_preflabel(self, lang=settings.LANGUAGE_CODE)

What it means is, use for  "lang" the value defined in
settings.LANGUAGE_CODE if nothing else is provided.
Most of the views take in a lang property as part of the request,
defaulting, again, to settings.LANGUAGE_CODE if none is provided.

eg: in app/views/concept.py on line 74
lang = request.GET.get('lang', settings.LANGUAGE_CODE)

what this means is that if your request has a "lang" property in the
querystring
eg: http://blahblahblah/concept/----111?lang=ar
then the language code "ar" should be passed on down to the get_preflabel
function with the language passed in from the request and it will not use
the value from settings.LANGUAGE_CODE

Hope that helps clarify how that all works.
Cheers,
Alexei


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

On Fri, Jun 10, 2016 at 11:44 AM,  wrote:

> In my case Alexei, this wouldn't work as I use the Middleware to operate
> language changes - settings.LANGUAGE_CODE would remain defaulted to en_US
> (the only lang code that I have assigned in settings.py). Instead, I have
> worked around this issue by replacing settings.LANGUAGE_CODE with
> translation.get_language().
>
> a.
>
> On Friday, June 10, 2016 at 7:22:20 PM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> There is a method in the models/concept.py file at line 375 called
>> "get_preflabel"
>>
>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
>>> ret = []
>>> if self.values == []:
>>> concept = Concept().get(id=self.id,
>>> include_subconcepts=False, include_parentconcepts=False, include=['label'])
>>> else:
>>> concept = self
>>> for value in concept.values:
>>> if value.type == 'prefLabel':
>>> if value.language == lang:
>>> return value
>>> elif value.language == lang.split('-')[0]:
>>> ret.insert(0, value)
>>> elif value.type == 'altLabel':
>>> if value.language == lang:
>>> ret.insert(0, value)
>>> ret.append(value)
>>> return ret[0] if len(ret) > 0 else ConceptValue()
>>
>>
>> that method has been updated in Arches v4 to this:
>>
>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
>>> score = 0
>>> ranked_labels = []
>>> if self.values == []:
>>> concept = Concept().get(id=self.id,
>>> include_subconcepts=False, include_parentconcepts=False, include=['label'])
>>> else:
>>> concept = self
>>> for value in concept.values:
>>> ranked_label = {
>>> 'weight': 1,
>>> 'value': value
>>> }
>>> if value.type == 'prefLabel':
>>> ranked_label['weight'] = ranked_label['weight'] * 10
>>> elif value.type == 'altLabel':
>>> ranked_label['weight'] = ranked_label['weight'] * 4
>>> if value.language == lang:
>>> ranked_label['weight'] = ranked_label['weight'] * 10
>>> elif value.language.split('-')[0] == lang.split('-')[0]:
>>> ranked_label['weight'] = ranked_label['weight'] * 5
>>> ranked_labels.append(ranked_label)
>>> ranked_labels = sorted(ranked_labels, key=lambda label:
>>> label['weight'], reverse=True)
>>> if len(ranked_labels) == 0:
>>> ranked_labels.append({
>>> 'weight': 1,
>>> 'value': ConceptValue()
>>> })
>>> return ranked_labels[0]['value']
>>
>>
>> as a test, you might try replacing the old method with the new one.
>> Also like I mentioned before, I would create prefLabels for all your
>> Arabic concepts.
>>
>> If that fixes the issue, I can update the v3 code accordingly and you
>> could then update your package from that.
>>
>> Hope that helps.
>> Cheers,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Fri, Jun 10, 2016 at 8:19 AM,  wrote:
>>
>>> That's what we had done in the beginning Alexei. However, for some
>>> unclear reason, it would appear that Arches selects among prefLabels across
>>> languages - so when we had all labels as prefLabels we ended up having some
>>> concepts in Arabic and some in English. I was only able to fix that by
>>> selecting altLabels instead. Any idea of why that error might have been
>>> occurring?
>>>
>>> Andrea
>>>
>>> On Thursday, June 9, 2016 at 5:40:54 PM UTC+1, Alexei Peters wrote:

 Hi Andrea,
 Instead of using altLabels for the Arabic language, you should use
 prefLabels.  Each language can (and should) specify a prefLabel.  Once you
 do that the system should be able to discern the correct label.
 I'll try and send another 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Thanks Bojan - and thanks Alexei. 

I have managed to manipulate labels in both the report page and in the E55 
dropdowns. However, I am still trying to find out how to manipulate the 
labels of the already selected branches. Where does the JSON resource graph 
(which is read by branch-list.js as an observable) get created ? I suspect 
this is what I should be looking for.

Thanks again,

Andrea



On Friday, June 10, 2016 at 9:50:37 PM UTC+1, Bojan Kastelic wrote:

> Hi Andrea,
> I had a similar problem and I also use request.LANGUAGE_CODE to switch to 
> selected language. In my project I didn't use resource manager (edit 
> pages), but I had the same problem with dropdowns in advanced search 
> . I also edited the function 
> get_e55_domain in models/concept.py 
>  
> (added param for language) and then I used the language from request to 
> fill domains in selected language (example in views/search.py 
> 
> ).
>
> Hope this helps.
>
> Bojan
>
> On Friday, June 10, 2016 at 8:44:10 PM UTC+2, zerbini...@gmail.com wrote:
>>
>> In my case Alexei, this wouldn't work as I use the Middleware to operate 
>> language changes - settings.LANGUAGE_CODE would remain defaulted to en_US 
>> (the only lang code that I have assigned in settings.py). Instead, I have 
>> worked around this issue by replacing settings.LANGUAGE_CODE with 
>> translation.get_language().
>>
>> a.
>>
>> On Friday, June 10, 2016 at 7:22:20 PM UTC+1, Alexei Peters wrote:
>>>
>>> Hi Andrea,
>>> There is a method in the models/concept.py file at line 375 called 
>>> "get_preflabel"
>>>
>>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
 ret = []
 if self.values == []: 
 concept = Concept().get(id=self.id, 
 include_subconcepts=False, include_parentconcepts=False, include=['label'])
 else:
 concept = self
 for value in concept.values:
 if value.type == 'prefLabel':
 if value.language == lang:
 return value
 elif value.language == lang.split('-')[0]:
 ret.insert(0, value)
 elif value.type == 'altLabel':
 if value.language == lang:
 ret.insert(0, value)
 ret.append(value)
 return ret[0] if len(ret) > 0 else ConceptValue()
>>>
>>>
>>> that method has been updated in Arches v4 to this:
>>>
>>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
 score = 0
 ranked_labels = []
 if self.values == []:
 concept = Concept().get(id=self.id, 
 include_subconcepts=False, include_parentconcepts=False, include=['label'])
 else:
 concept = self
 for value in concept.values:
 ranked_label = {
 'weight': 1,
 'value': value
 }
 if value.type == 'prefLabel':
 ranked_label['weight'] = ranked_label['weight'] * 10
 elif value.type == 'altLabel':
 ranked_label['weight'] = ranked_label['weight'] * 4
 if value.language == lang:
 ranked_label['weight'] = ranked_label['weight'] * 10
 elif value.language.split('-')[0] == lang.split('-')[0]:
 ranked_label['weight'] = ranked_label['weight'] * 5
 ranked_labels.append(ranked_label)
 ranked_labels = sorted(ranked_labels, key=lambda label: 
 label['weight'], reverse=True)
 if len(ranked_labels) == 0:
 ranked_labels.append({
 'weight': 1,
 'value': ConceptValue()
 })
 return ranked_labels[0]['value'] 
>>>
>>>
>>> as a test, you might try replacing the old method with the new one.
>>> Also like I mentioned before, I would create prefLabels for all your 
>>> Arabic concepts.
>>>
>>> If that fixes the issue, I can update the v3 code accordingly and you 
>>> could then update your package from that.
>>>
>>> Hope that helps.
>>> Cheers,
>>> Alexei
>>>
>>>
>>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>>
>>> On Fri, Jun 10, 2016 at 8:19 AM,  wrote:
>>>
 That's what we had done in the beginning Alexei. However, for some 
 unclear reason, it would appear that Arches selects among prefLabels 
 across 
 languages - so when we had all labels as prefLabels we ended up having 
 some 
 concepts in Arabic and some in English. I was only able to fix that by 
 selecting altLabels instead. Any idea of why that error might have been 
 occurring?

 Andrea

Re: [Arches] Re: Accessing languages via Django

[Bojan Kastelic]

Hi Andrea,
I had a similar problem and I also use request.LANGUAGE_CODE to switch to 
selected language. In my project I didn't use resource manager (edit 
pages), but I had the same problem with dropdowns in advanced search 
. I also edited the function 
get_e55_domain in models/concept.py 
 
(added param for language) and then I used the language from request to 
fill domains in selected language (example in views/search.py 
).

Hope this helps.

Bojan

On Friday, June 10, 2016 at 8:44:10 PM UTC+2, zerbini...@gmail.com wrote:
>
> In my case Alexei, this wouldn't work as I use the Middleware to operate 
> language changes - settings.LANGUAGE_CODE would remain defaulted to en_US 
> (the only lang code that I have assigned in settings.py). Instead, I have 
> worked around this issue by replacing settings.LANGUAGE_CODE with 
> translation.get_language().
>
> a.
>
> On Friday, June 10, 2016 at 7:22:20 PM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> There is a method in the models/concept.py file at line 375 called 
>> "get_preflabel"
>>
>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
>>> ret = []
>>> if self.values == []: 
>>> concept = Concept().get(id=self.id, 
>>> include_subconcepts=False, include_parentconcepts=False, include=['label'])
>>> else:
>>> concept = self
>>> for value in concept.values:
>>> if value.type == 'prefLabel':
>>> if value.language == lang:
>>> return value
>>> elif value.language == lang.split('-')[0]:
>>> ret.insert(0, value)
>>> elif value.type == 'altLabel':
>>> if value.language == lang:
>>> ret.insert(0, value)
>>> ret.append(value)
>>> return ret[0] if len(ret) > 0 else ConceptValue()
>>
>>
>> that method has been updated in Arches v4 to this:
>>
>> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
>>> score = 0
>>> ranked_labels = []
>>> if self.values == []:
>>> concept = Concept().get(id=self.id, 
>>> include_subconcepts=False, include_parentconcepts=False, include=['label'])
>>> else:
>>> concept = self
>>> for value in concept.values:
>>> ranked_label = {
>>> 'weight': 1,
>>> 'value': value
>>> }
>>> if value.type == 'prefLabel':
>>> ranked_label['weight'] = ranked_label['weight'] * 10
>>> elif value.type == 'altLabel':
>>> ranked_label['weight'] = ranked_label['weight'] * 4
>>> if value.language == lang:
>>> ranked_label['weight'] = ranked_label['weight'] * 10
>>> elif value.language.split('-')[0] == lang.split('-')[0]:
>>> ranked_label['weight'] = ranked_label['weight'] * 5
>>> ranked_labels.append(ranked_label)
>>> ranked_labels = sorted(ranked_labels, key=lambda label: 
>>> label['weight'], reverse=True)
>>> if len(ranked_labels) == 0:
>>> ranked_labels.append({
>>> 'weight': 1,
>>> 'value': ConceptValue()
>>> })
>>> return ranked_labels[0]['value'] 
>>
>>
>> as a test, you might try replacing the old method with the new one.
>> Also like I mentioned before, I would create prefLabels for all your 
>> Arabic concepts.
>>
>> If that fixes the issue, I can update the v3 code accordingly and you 
>> could then update your package from that.
>>
>> Hope that helps.
>> Cheers,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Fri, Jun 10, 2016 at 8:19 AM,  wrote:
>>
>>> That's what we had done in the beginning Alexei. However, for some 
>>> unclear reason, it would appear that Arches selects among prefLabels across 
>>> languages - so when we had all labels as prefLabels we ended up having some 
>>> concepts in Arabic and some in English. I was only able to fix that by 
>>> selecting altLabels instead. Any idea of why that error might have been 
>>> occurring?
>>>
>>> Andrea
>>>
>>> On Thursday, June 9, 2016 at 5:40:54 PM UTC+1, Alexei Peters wrote:

 Hi Andrea,
 Instead of using altLabels for the Arabic language, you should use 
 prefLabels.  Each language can (and should) specify a prefLabel.  Once you 
 do that the system should be able to discern the correct label.  
 I'll try and send another email with more detail on how to set up an 
 end point to switch the language.
 Cheers,
 Alexei


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

 On Wed, Jun 8, 2016 at 7:43 AM, 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

In my case Alexei, this wouldn't work as I use the Middleware to operate 
language changes - settings.LANGUAGE_CODE would remain defaulted to en_US 
(the only lang code that I have assigned in settings.py). Instead, I have 
worked around this issue by replacing settings.LANGUAGE_CODE with 
translation.get_language().

a.

On Friday, June 10, 2016 at 7:22:20 PM UTC+1, Alexei Peters wrote:
>
> Hi Andrea,
> There is a method in the models/concept.py file at line 375 called 
> "get_preflabel"
>
> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
>> ret = []
>> if self.values == []: 
>> concept = Concept().get(id=self.id, 
>> include_subconcepts=False, include_parentconcepts=False, include=['label'])
>> else:
>> concept = self
>> for value in concept.values:
>> if value.type == 'prefLabel':
>> if value.language == lang:
>> return value
>> elif value.language == lang.split('-')[0]:
>> ret.insert(0, value)
>> elif value.type == 'altLabel':
>> if value.language == lang:
>> ret.insert(0, value)
>> ret.append(value)
>> return ret[0] if len(ret) > 0 else ConceptValue()
>
>
> that method has been updated in Arches v4 to this:
>
> def get_preflabel(self, lang=settings.LANGUAGE_CODE):
>> score = 0
>> ranked_labels = []
>> if self.values == []:
>> concept = Concept().get(id=self.id, 
>> include_subconcepts=False, include_parentconcepts=False, include=['label'])
>> else:
>> concept = self
>> for value in concept.values:
>> ranked_label = {
>> 'weight': 1,
>> 'value': value
>> }
>> if value.type == 'prefLabel':
>> ranked_label['weight'] = ranked_label['weight'] * 10
>> elif value.type == 'altLabel':
>> ranked_label['weight'] = ranked_label['weight'] * 4
>> if value.language == lang:
>> ranked_label['weight'] = ranked_label['weight'] * 10
>> elif value.language.split('-')[0] == lang.split('-')[0]:
>> ranked_label['weight'] = ranked_label['weight'] * 5
>> ranked_labels.append(ranked_label)
>> ranked_labels = sorted(ranked_labels, key=lambda label: 
>> label['weight'], reverse=True)
>> if len(ranked_labels) == 0:
>> ranked_labels.append({
>> 'weight': 1,
>> 'value': ConceptValue()
>> })
>> return ranked_labels[0]['value'] 
>
>
> as a test, you might try replacing the old method with the new one.
> Also like I mentioned before, I would create prefLabels for all your 
> Arabic concepts.
>
> If that fixes the issue, I can update the v3 code accordingly and you 
> could then update your package from that.
>
> Hope that helps.
> Cheers,
> Alexei
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Fri, Jun 10, 2016 at 8:19 AM,  
> wrote:
>
>> That's what we had done in the beginning Alexei. However, for some 
>> unclear reason, it would appear that Arches selects among prefLabels across 
>> languages - so when we had all labels as prefLabels we ended up having some 
>> concepts in Arabic and some in English. I was only able to fix that by 
>> selecting altLabels instead. Any idea of why that error might have been 
>> occurring?
>>
>> Andrea
>>
>> On Thursday, June 9, 2016 at 5:40:54 PM UTC+1, Alexei Peters wrote:
>>>
>>> Hi Andrea,
>>> Instead of using altLabels for the Arabic language, you should use 
>>> prefLabels.  Each language can (and should) specify a prefLabel.  Once you 
>>> do that the system should be able to discern the correct label.  
>>> I'll try and send another email with more detail on how to set up an end 
>>> point to switch the language.
>>> Cheers,
>>> Alexei
>>>
>>>
>>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>>
>>> On Wed, Jun 8, 2016 at 7:43 AM,  wrote:
>>>
 Thank you Alexei. As it happens, I had already,and successfully, set up 
 an Arabic translation of all of the static strings (the ones read by 
 Django's gettext). This works fine, though I am not too happy with having 
 Django automatically select a language based on Middleware: I'd much 
 rather 
 be able to switch languages at will by using the language dropdown in the 
 header.

 The major issue is how to get the app to display the alternative Arabic 
 labels that we entered in the RDM for each node and concept. Once I set up 
 my custom context processor to loop through the languages in the header, 
 the two languages  will display correctly of course, but that won't be 
 enough  unless I build the language dropdown within a form that, when 
 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Hi Phil,

I did find a solution, which you can see here: 
https://github.com/azerbini/eamena2/blob/app/models/concept.py. I edited 
the function get_55_domain() adding further WHERE clauses to the SELECT 
query that populates the dropdowns. The additional clause is to select the 
appropriate language as obtained via translation.get_language(). I pass 
this as an additional argument of format(). In this way, only the labels 
consistent with the selected language are displayed.

In order to display the correct labels in the resource report page, I have 
simply changed settings.LANGUAGE_CODE to request.LANGUAGE_CODE so that the 
code is taken from the Middleware and not from settings.py 
(https://github.com/azerbini/eamena2/blob/views/resources.py). This is 
sufficient to display the report page in the correct language now. 

I have now got a final hurdle to overcome, namely assigning the right 
language to the branches populated via the JS libraries. Alexei, could you 
please point me to the python file and class which produces the JSON mapped 
by branch-list.js ? Thanks! 


On Friday, June 10, 2016 at 4:22:54 PM UTC+1, Carlisle, Philip wrote:
>
> Hi Andrea
>
> I think this is a bug relating to the order that the terms are added. I 
> did find a work around but it’s so long ago I forget what it was. I did 
> this when creating the MENA vocabulary that you can see in the RDM on the 
> Demo site.
>
>  
>
> Not much help I know but as it’s a bug it ought to get fixed.
>
>  
>
> Phil
>
>  
>
> *Phil Carlisle*
>
> Data Standards Supervisor
>
> Knowledge Organisation Services
>
> Listing Information Services
>
> Listing Group
>
> Historic England
>
> The Engine House
>
> Fire Fly Avenue
>
> Swindon
>
> SN2 2EH
>
> Tel: +44 (0)1793 414824
>
>  
>
> http://thesaurus.historicengland.org.uk/ 
>
> http://www.heritagedata.org/blog/
>
>  
>
> Listing Information Services fosters an environment where colleagues are 
> valued for their skills and knowledge, and where communication, customer 
> focus and working in partnership are at the heart of everything we do.
>
>  
>
> For the first time ever, you can now share your knowledge and photos on 
> the nation's list of historic buildings and places 
> www.historicengland.org.uk/ETL #ListEngland
>
>  
>
>  
>
> *From:* arches...@googlegroups.com  [mailto:
> arches...@googlegroups.com ] *On Behalf Of *
> zerbini...@gmail.com 
> *Sent:* 10 June 2016 16:20
> *To:* Arches Project
> *Subject:* Re: [Arches] Re: Accessing languages via Django
>
>  
>
> That's what we had done in the beginning Alexei. However, for some unclear 
> reason, it would appear that Arches selects among prefLabels across 
> languages - so when we had all labels as prefLabels we ended up having some 
> concepts in Arabic and some in English. I was only able to fix that by 
> selecting altLabels instead. Any idea of why that error might have been 
> occurring?
>
>  
>
> Andrea
>
>
> On Thursday, June 9, 2016 at 5:40:54 PM UTC+1, Alexei Peters wrote:
>
> Hi Andrea,
>
> Instead of using altLabels for the Arabic language, you should use 
> prefLabels.  Each language can (and should) specify a prefLabel.  Once you 
> do that the system should be able to discern the correct label.  
>
> I'll try and send another email with more detail on how to set up an end 
> point to switch the language.
>
> Cheers,
>
> Alexei
>
>
>  
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
>  
>
> On Wed, Jun 8, 2016 at 7:43 AM, <zerbini...@gmail.com> wrote:
>
> Thank you Alexei. As it happens, I had already,and successfully, set up an 
> Arabic translation of all of the static strings (the ones read by Django's 
> gettext). This works fine, though I am not too happy with having Django 
> automatically select a language based on Middleware: I'd much rather be 
> able to switch languages at will by using the language dropdown in the 
> header.
>
>  
>
> The major issue is how to get the app to display the alternative Arabic 
> labels that we entered in the RDM for each node and concept. Once I set up 
> my custom context processor to loop through the languages in the header, 
> the two languages  will display correctly of course, but that won't be 
> enough  unless I build the language dropdown within a form that, when 
> posted, leads the app to switch from prefLabels in en_US to altLabels in 
> ar. *This* is the point on which I would really welcome your input. Have 
> you already written some code to manipulate label visualisation?
>
>  
>
> Best,
>
>  
>
> Andrea
>
>
> On Monday, June 6, 2

Re: [Arches] Re: Accessing languages via Django

[Alexei Peters]

Hi Andrea,
There is a method in the models/concept.py file at line 375 called
"get_preflabel"

def get_preflabel(self, lang=settings.LANGUAGE_CODE):
> ret = []
> if self.values == []:
> concept = Concept().get(id=self.id,
> include_subconcepts=False, include_parentconcepts=False, include=['label'])
> else:
> concept = self
> for value in concept.values:
> if value.type == 'prefLabel':
> if value.language == lang:
> return value
> elif value.language == lang.split('-')[0]:
> ret.insert(0, value)
> elif value.type == 'altLabel':
> if value.language == lang:
> ret.insert(0, value)
> ret.append(value)
> return ret[0] if len(ret) > 0 else ConceptValue()


that method has been updated in Arches v4 to this:

def get_preflabel(self, lang=settings.LANGUAGE_CODE):
> score = 0
> ranked_labels = []
> if self.values == []:
> concept = Concept().get(id=self.id,
> include_subconcepts=False, include_parentconcepts=False, include=['label'])
> else:
> concept = self
> for value in concept.values:
> ranked_label = {
> 'weight': 1,
> 'value': value
> }
> if value.type == 'prefLabel':
> ranked_label['weight'] = ranked_label['weight'] * 10
> elif value.type == 'altLabel':
> ranked_label['weight'] = ranked_label['weight'] * 4
> if value.language == lang:
> ranked_label['weight'] = ranked_label['weight'] * 10
> elif value.language.split('-')[0] == lang.split('-')[0]:
> ranked_label['weight'] = ranked_label['weight'] * 5
> ranked_labels.append(ranked_label)
> ranked_labels = sorted(ranked_labels, key=lambda label:
> label['weight'], reverse=True)
> if len(ranked_labels) == 0:
> ranked_labels.append({
> 'weight': 1,
> 'value': ConceptValue()
> })
> return ranked_labels[0]['value']


as a test, you might try replacing the old method with the new one.
Also like I mentioned before, I would create prefLabels for all your Arabic
concepts.

If that fixes the issue, I can update the v3 code accordingly and you could
then update your package from that.

Hope that helps.
Cheers,
Alexei


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

On Fri, Jun 10, 2016 at 8:19 AM,  wrote:

> That's what we had done in the beginning Alexei. However, for some unclear
> reason, it would appear that Arches selects among prefLabels across
> languages - so when we had all labels as prefLabels we ended up having some
> concepts in Arabic and some in English. I was only able to fix that by
> selecting altLabels instead. Any idea of why that error might have been
> occurring?
>
> Andrea
>
> On Thursday, June 9, 2016 at 5:40:54 PM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> Instead of using altLabels for the Arabic language, you should use
>> prefLabels.  Each language can (and should) specify a prefLabel.  Once you
>> do that the system should be able to discern the correct label.
>> I'll try and send another email with more detail on how to set up an end
>> point to switch the language.
>> Cheers,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Wed, Jun 8, 2016 at 7:43 AM,  wrote:
>>
>>> Thank you Alexei. As it happens, I had already,and successfully, set up
>>> an Arabic translation of all of the static strings (the ones read by
>>> Django's gettext). This works fine, though I am not too happy with having
>>> Django automatically select a language based on Middleware: I'd much rather
>>> be able to switch languages at will by using the language dropdown in the
>>> header.
>>>
>>> The major issue is how to get the app to display the alternative Arabic
>>> labels that we entered in the RDM for each node and concept. Once I set up
>>> my custom context processor to loop through the languages in the header,
>>> the two languages  will display correctly of course, but that won't be
>>> enough  unless I build the language dropdown within a form that, when
>>> posted, leads the app to switch from prefLabels in en_US to altLabels in
>>> ar. *This* is the point on which I would really welcome your input.
>>> Have you already written some code to manipulate label visualisation?
>>>
>>> Best,
>>>
>>> Andrea
>>>
>>> On Monday, June 6, 2016 at 10:15:13 PM UTC+1, Alexei Peters wrote:

 Hi Andrea,
 You'll actually have to do several things to present the site in
 another language.

1. You'll have to add supply your own version of the
template/header.htm file and as you mentioned loop 

Re: [Arches] Re: Accessing languages via Django

[Alexei Peters]

Hi Andrea,
Instead of using altLabels for the Arabic language, you should use
prefLabels.  Each language can (and should) specify a prefLabel.  Once you
do that the system should be able to discern the correct label.
I'll try and send another email with more detail on how to set up an end
point to switch the language.
Cheers,
Alexei


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

On Wed, Jun 8, 2016 at 7:43 AM,  wrote:

> Thank you Alexei. As it happens, I had already,and successfully, set up an
> Arabic translation of all of the static strings (the ones read by Django's
> gettext). This works fine, though I am not too happy with having Django
> automatically select a language based on Middleware: I'd much rather be
> able to switch languages at will by using the language dropdown in the
> header.
>
> The major issue is how to get the app to display the alternative Arabic
> labels that we entered in the RDM for each node and concept. Once I set up
> my custom context processor to loop through the languages in the header,
> the two languages  will display correctly of course, but that won't be
> enough  unless I build the language dropdown within a form that, when
> posted, leads the app to switch from prefLabels in en_US to altLabels in
> ar. *This* is the point on which I would really welcome your input. Have
> you already written some code to manipulate label visualisation?
>
> Best,
>
> Andrea
>
> On Monday, June 6, 2016 at 10:15:13 PM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> You'll actually have to do several things to present the site in another
>> language.
>>
>>1. You'll have to add supply your own version of the
>>template/header.htm file and as you mentioned loop through the languages
>>provided by the system.  To do that you'll probably want to add a context
>>processor that get's the language information from the database.  See
>>arches/app/utils/context_processors.py for examples.  Once you've created
>>that, then add a reference to it in the TEMPLATE_CONTEXT_PROCESSORS 
>> section
>>of settings.py.  Once you've done this you should be able to access the
>>languages from your new header.htm template.
>>2. In settings.py go to MIDDLEWARE_CLASSES and uncomment the line:
>>'django.middleware.locale.LocaleMiddleware'
>>3. Read the section entitled "How Django discovers language
>>preference" in the reference documentation found here:
>>https://media.readthedocs.org/pdf/django/1.6.x/django.pdf . There are
>>several ways to set the language, but the easiest might be to set a 
>> cookie.
>>
>> Once you've done those things you should be well on your way to
>> displaying your site in Arabic.
>> Chees,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Mon, Jun 6, 2016 at 7:12 AM,  wrote:
>>
>>> I am not sure I explained myself correctly Adam. Let me try again: we
>>> have translated our entire platform in Arabic, including both the static
>>> strings which Django reads via the .mo file and our nodes and concepts. The
>>> translations for the latter two have been entered via the RDM as altLabels
>>> selecting Arabic as a language. Arabic had been previously added as a
>>> language via the Django admin panel (Models -> d_languages).
>>>
>>> Now, what I want to do is to be able to select the appropriate app
>>> language in the header dropdown so that, when I select Arabic, I get the
>>> whole app to be shown in Arabic. Do I have to write this whole class from
>>> scratch? Or does something exist already to support multilingual apps?
>>>
>>> Andrea
>>>
>>>
>>> On Wednesday, June 1, 2016 at 10:38:48 PM UTC+1, Adam Cox wrote:

 Hi Andrea, technically this is possible, but I don't think it would do
 what you are hoping... The Languages dropdown is meant to be configured to
 allow the user to change the app's interface language, while the language
 concepts are only meant to be attributes for a resource (the language that
 an Information Resource is written in, for example).

 Adam

 On Wednesday, May 25, 2016 at 12:59:08 AM UTC-6, zerbini...@gmail.com
 wrote:
>
> Hi All,
>
> I am in need to change the static 'Languages' dropdown menu in the
> header.htm template to a dynamic one looping through the list of languages
> in the concepts.d_languages table. Has someone already written this code ?
> I couldn't figure out how to read the language table via Django tags.
>
> Best,
>
> Andrea
>
 --
>>> -- To post, send email to arches...@googlegroups.com. To unsubscribe,
>>> send email to archesprojec...@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 

Re: [Arches] Re: Accessing languages via Django

[zerbini . eamena]

Thank you Alexei. As it happens, I had already,and successfully, set up an 
Arabic translation of all of the static strings (the ones read by Django's 
gettext). This works fine, though I am not too happy with having Django 
automatically select a language based on Middleware: I'd much rather be 
able to switch languages at will by using the language dropdown in the 
header.

The major issue is how to get the app to display the alternative Arabic 
labels that we entered in the RDM for each node and concept. Once I set up 
my custom context processor to loop through the languages in the header, 
the two languages  will display correctly of course, but that won't be 
enough  unless I build the language dropdown within a form that, when 
posted, leads the app to switch from prefLabels in en_US to altLabels in 
ar. *This* is the point on which I would really welcome your input. Have 
you already written some code to manipulate label visualisation?

Best,

Andrea

On Monday, June 6, 2016 at 10:15:13 PM UTC+1, Alexei Peters wrote:
>
> Hi Andrea, 
> You'll actually have to do several things to present the site in another 
> language.
>
>1. You'll have to add supply your own version of the 
>template/header.htm file and as you mentioned loop through the languages 
>provided by the system.  To do that you'll probably want to add a context 
>processor that get's the language information from the database.  See 
>arches/app/utils/context_processors.py for examples.  Once you've created 
>that, then add a reference to it in the TEMPLATE_CONTEXT_PROCESSORS 
> section 
>of settings.py.  Once you've done this you should be able to access the 
>languages from your new header.htm template.
>2. In settings.py go to MIDDLEWARE_CLASSES and uncomment the line: 
>'django.middleware.locale.LocaleMiddleware'
>3. Read the section entitled "How Django discovers language 
>preference" in the reference documentation found here: 
>https://media.readthedocs.org/pdf/django/1.6.x/django.pdf . There are 
>several ways to set the language, but the easiest might be to set a cookie.
>
> Once you've done those things you should be well on your way to displaying 
> your site in Arabic.
> Chees,
> Alexei
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Mon, Jun 6, 2016 at 7:12 AM,  
> wrote:
>
>> I am not sure I explained myself correctly Adam. Let me try again: we 
>> have translated our entire platform in Arabic, including both the static 
>> strings which Django reads via the .mo file and our nodes and concepts. The 
>> translations for the latter two have been entered via the RDM as altLabels 
>> selecting Arabic as a language. Arabic had been previously added as a 
>> language via the Django admin panel (Models -> d_languages).
>>
>> Now, what I want to do is to be able to select the appropriate app 
>> language in the header dropdown so that, when I select Arabic, I get the 
>> whole app to be shown in Arabic. Do I have to write this whole class from 
>> scratch? Or does something exist already to support multilingual apps?
>>
>> Andrea
>>
>>
>> On Wednesday, June 1, 2016 at 10:38:48 PM UTC+1, Adam Cox wrote:
>>>
>>> Hi Andrea, technically this is possible, but I don't think it would do 
>>> what you are hoping... The Languages dropdown is meant to be configured to 
>>> allow the user to change the app's interface language, while the language 
>>> concepts are only meant to be attributes for a resource (the language that 
>>> an Information Resource is written in, for example).
>>>
>>> Adam
>>>
>>> On Wednesday, May 25, 2016 at 12:59:08 AM UTC-6, zerbini...@gmail.com 
>>> wrote:

 Hi All,

 I am in need to change the static 'Languages' dropdown menu in the 
 header.htm template to a dynamic one looping through the list of languages 
 in the concepts.d_languages table. Has someone already written this code ? 
 I couldn't figure out how to read the language table via Django tags. 

 Best,

 Andrea

>>> -- 
>> -- To post, send email to arches...@googlegroups.com . To 
>> unsubscribe, send email to archesprojec...@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 archesprojec...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
-- 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 

Re: [Arches] Re: Accessing languages via Django

[Adam Cox]

You're correct, that's not what I was thinking. I know that Arches/Django
does support multiple languages for the app's interface, but I haven't
explored this option myself yet.  I'll be interested to know what you find,
and if I can look into it soon I'll let you know.

Adam

On Mon, Jun 6, 2016 at 8:12 AM,  wrote:

> I am not sure I explained myself correctly Adam. Let me try again: we have
> translated our entire platform in Arabic, including both the static strings
> which Django reads via the .mo file and our nodes and concepts. The
> translations for the latter two have been entered via the RDM as altLabels
> selecting Arabic as a language. Arabic had been previously added as a
> language via the Django admin panel (Models -> d_languages).
>
> Now, what I want to do is to be able to select the appropriate app
> language in the header dropdown so that, when I select Arabic, I get the
> whole app to be shown in Arabic. Do I have to write this whole class from
> scratch? Or does something exist already to support multilingual apps?
>
> Andrea
>
>
> On Wednesday, June 1, 2016 at 10:38:48 PM UTC+1, Adam Cox wrote:
>>
>> Hi Andrea, technically this is possible, but I don't think it would do
>> what you are hoping... The Languages dropdown is meant to be configured to
>> allow the user to change the app's interface language, while the language
>> concepts are only meant to be attributes for a resource (the language that
>> an Information Resource is written in, for example).
>>
>> Adam
>>
>> On Wednesday, May 25, 2016 at 12:59:08 AM UTC-6, zerbini...@gmail.com
>> wrote:
>>>
>>> Hi All,
>>>
>>> I am in need to change the static 'Languages' dropdown menu in the
>>> header.htm template to a dynamic one looping through the list of languages
>>> in the concepts.d_languages table. Has someone already written this code ?
>>> I couldn't figure out how to read the language table via Django tags.
>>>
>>> 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.
>

-- 
-- 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.

[Arches] Re: Accessing languages via Django

[zerbini . eamena]

I am not sure I explained myself correctly Adam. Let me try again: we have 
translated our entire platform in Arabic, including both the static strings 
which Django reads via the .mo file and our nodes and concepts. The 
translations for the latter two have been entered via the RDM as altLabels 
selecting Arabic as a language. Arabic had been previously added as a 
language via the Django admin panel (Models -> d_languages).

Now, what I want to do is to be able to select the appropriate app language 
in the header dropdown so that, when I select Arabic, I get the whole app 
to be shown in Arabic. Do I have to write this whole class from scratch? Or 
does something exist already to support multilingual apps?

Andrea

On Wednesday, June 1, 2016 at 10:38:48 PM UTC+1, Adam Cox wrote:
>
> Hi Andrea, technically this is possible, but I don't think it would do 
> what you are hoping... The Languages dropdown is meant to be configured to 
> allow the user to change the app's interface language, while the language 
> concepts are only meant to be attributes for a resource (the language that 
> an Information Resource is written in, for example).
>
> Adam
>
> On Wednesday, May 25, 2016 at 12:59:08 AM UTC-6, zerbini...@gmail.com 
> wrote:
>>
>> Hi All,
>>
>> I am in need to change the static 'Languages' dropdown menu in the 
>> header.htm template to a dynamic one looping through the list of languages 
>> in the concepts.d_languages table. Has someone already written this code ? 
>> I couldn't figure out how to read the language table via Django tags. 
>>
>> 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.

[Arches] Re: Accessing languages via Django

[Adam Cox]

Hi Andrea, technically this is possible, but I don't think it would do what 
you are hoping... The Languages dropdown is meant to be configured to allow 
the user to change the app's interface language, while the language 
concepts are only meant to be attributes for a resource (the language that 
an Information Resource is written in, for example).

Adam

On Wednesday, May 25, 2016 at 12:59:08 AM UTC-6, zerbini...@gmail.com wrote:
>
> Hi All,
>
> I am in need to change the static 'Languages' dropdown menu in the 
> header.htm template to a dynamic one looping through the list of languages 
> in the concepts.d_languages table. Has someone already written this code ? 
> I couldn't figure out how to read the language table via Django tags. 
>
> 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.