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:* [email protected] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of * > [email protected] <javascript:> > *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, <[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] <javascript:>. To > unsubscribe, send email to [email protected] <javascript:>. > 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] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > We are the public body that looks after England's historic environment. We > champion historic places, helping people to understand, value and care for > them, now and for the future. > Sign up to our enewsletter to keep up to date with our latest news, advice > and listings. > HistoricEngland.org.uk Twitter: @HistoricEngland > > This e-mail (and any attachments) is confidential and may contain personal > views which are not the views of Historic England unless specifically stated. > If you have received it in error, please delete it from your system and > notify the sender immediately. Do not use, copy or disclose the information > in any way nor act in reliance on it. Any information sent to Historic > England may become publicly available. > > > > -- -- 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.
