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: [email protected] 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, [email protected] 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, <[email protected]> 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, [email protected] 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: <class 'arches.app.models.entity.Entity'>: 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, [email protected] 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/11111111-1111-1111-1111-11111111111?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, <[email protected]> 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, <[email protected]> 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, <[email protected]> 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, <[email protected]> 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, [email protected] 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 [email protected]. To unsubscribe, send email to [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to a topic in the Google Groups "Arches Project" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/archesproject/YTopbQdPDQg/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
