Changing language doesn't work when the language is defined in the page

[monzug]

this is related to issue #703 - the scope and title of the issue were changed. today I was able to reproduce the original issue:
when I have default language greek, and I do enter a latin word in lookup, the change language to latin does not take effect, so lookup fails. I have to select Greek and then Latin again from the drop-down in order to work.

to repro in build 3.0.0.53
have default language set to greek in options, then go to latin text. double click on any latin word, the lookup will fail with the option to change language from Greek to Latin. click on the close button, next lookup will fail again. only when switching language from latin to greek and back to latin from drop-down , the lookup will not fail.
this scenario is only reproducible when change language is from Greek to Latin (or the other way)

[balmas]

hmm. I cannot reproduce this. I did these steps:

on a latin library text

default language in settings set to greek
click on a word
in the language fail notice, Greek is preselected, change it to Latin
close the popup
lookup another word
it correctly uses latin

[monzug]

not easy to repro, specially after fixing #703. you have to have a situation in which on latin text you have a pop-up in which it says language not greek. change to latin.
see screenshot in #703

[monzug]

[monzug]

to repro:
from above latin library text, I change page language to greek in options, then I enter a greek word in lookup. then I double click a latin word from text. that's when I start getting the above message and the switch to latin works only when I select greek and then latin from drop-down

[monzug]

I was able to reproduce a similar scenario in safari build 3.0.0.53 in which Venus worked from lookup but not from double-click
see screenshot

[balmas]

@irina060981 can you try investigating this? Thank you!

[irina060981]

I couldn't understand it quitely

As I could see steps are the following:
- options page language = greek (then when you double click any word it tries to search all in greek, if other is not defined in page layout directly)
- lookup language doesn't update from the page language setting (that's why it has Latin)
- double click on any word - it shows the message - no in Greek (got from settings) - change to Latin?
- you change to Latin (it updates page setting to Latin) and then double-click again
- it searches in Latin with success

These steps I could guess from the description and screenshots.
I see the same steps and even I spent time to describe it in video tutorial because it could be rather confusing.

But no I am confused :)
@balmas, @monzug , What is not working correctly here?

[monzug]

Irina, try the following. go to https://www.loebclassics.com/view/augustus-res_gestae/1924/pb_LCL152.345.xml?rskey=U4vflA&result=1 and log in. text is in both languages, latin and greek. activate alpheios (page language is Latin), double click on a greek word. it will say that the word is not found in the Latin resources, wrong language? change to: select greek from drop-down. double click again to an other greek word, you will still get the same message over and over.

…

On Tue, Aug 20, 2019 at 5:47 AM Sklyarova Irina ***@***.***> wrote: I couldn't understand it quitely As I could see steps are the following: - options page language = greek (then when you double click any word it tries to search all in greek, if other is not defined in page layout directly) - lookup language doesn't update from the page language setting (that's why it has Latin) - double click on any word - it shows the message - no in Greek (got from settings) - change to Latin? - you change to Latin (it updates page setting to Latin) and then double-click again - it searches in Latin with success These steps I could guess from the description and screenshots. I see the same steps and even I spent time to describe it in video tutorial because it could be rather confusing. But no I am confused :) @balmas <https://github.com/balmas>, @monzug <https://github.com/monzug> , What is not working correctly here? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#746?email_source=notifications&email_token=AJ32UOL7K4DBTVFLBENXYMTQFO4TNA5CNFSM4IKUMNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4VW7PA#issuecomment-522940348>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ32UOKOQUPVLFQSDW6GDK3QFO4TNANCNFSM4IKUMNCQ> .

[balmas]

ah... I think I see what's failing here.

The Loeb site has the greek text with an ancester html element which identifies the language as latin.

So the change in the select box IS taking effect, but it is being overridden by the page markup.

<section class="div1 language" lang="la"><header><hgroup><h1><span class="hi">Res</span> <span class="hi">Gestae</span> Divi Augusti</h1></hgroup></header>
<section class="div2">
<h2><span class="ac"><span class="hi">Res</span> <span class="hi">Gestae</span> Divi Augusti</span></h2>

<p>Rérum<a href="#note_LCL152_344_1" class="footnoteLink" id="target_note_LCL152_344_1"><sup>1</sup></a> gestárum díví Augusti, quibus orbem terra-(<span class="italic">rum</span>) ímperio populi Rom. subiécit, § et inpensarum, quas in rem publicam populumque Ro(<span class="italic">ma</span>)num fecit, incísarum in duabus aheneís pílís, quae su(<span class="italic">n</span>)t Romae positae, exemplar sub(<span class="italic">i</span>)ectum.</p>
</section>

<section class="div2">
<p><span class="marginNote left partNote">I</span>1 Annós undéviginti natus exercitum priváto consilio et privatá impensá | comparávi, (§) per quem rem publicam (<span class="italic">do</span>)minatione factionis oppressam | in</p>

<p>Μεθηρμηνευμέναι ὑπεγράφησαν πράξεις τε καὶ
δωρεαὶ Σεβαστοῦ θεοῦ, ἃς ἀπέλιπεν ἐπὶ Ῥώμης
ἐνκεχαραγμένας χαλκαῖς στήλαις δυσί.</p>
</section>

[balmas]

We don't actually offer the option to override the page markup. I think this one might have to wait.

[monzug]

ok. but I have experienced this situation in almost all sites not just loeb. it's just not easy to repro

…

On Tue, Aug 20, 2019 at 8:56 AM Bridget Almas ***@***.***> wrote: We don't actually offer the option to override the page markup. I think this one might have to wait. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#746?email_source=notifications&email_token=AJ32UOOFNRYHBJWI3UXWAPLQFPSYXA5CNFSM4IKUMNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4WF6KI#issuecomment-523001641>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ32UOOBJALF3RD2CYQAQ23QFPSYXANCNFSM4IKUMNCQ> .

[balmas]

hmm. ok. that was what I was going to ask, if you were able to reproduce elsewhere. If that's the case, then my analysis is not correct.

[monzug]

but it's correct to say that we don't override the page language when offering to change language

[balmas]

I cannot reproduce it in a scenario where the language is not defined in the page markup.

[irina060981]

i have checked the code - and @balmas , you are right.
It works with the following steps:

• selected text is sent via event/domEvent

• it defines the language from the source (each time selection is done); and if it is not defined, it gets the default language from options

  on the current Loeb link - lang=la is defined for the whole left text - for the latin part and for the greek part.
  So Latin language would be applied to any selection in both pieces of text

[irina060981]

@monzug and @balmas ,
May be then we could close this issue and reopen when someone will find the link with the scenario - page language is not defined, but default language is overwritten?

[balmas]

well, I would like to leave this open for the scenario we have identified. We won't probably fix it for this release but it should be possible to override page language, so we want to keep that for an incremental future release. I will update the title. @monzug if you can reproduce in another scenario, let's open a separate issue for that.

[monzug]

sounds good to me.

…

On Thu, Aug 22, 2019 at 8:00 AM Bridget Almas ***@***.***> wrote: well, I would like to leave this open for the scenario we have identified. We won't probably fix it for this release but it should be possible to override page language, so we want to keep that for an incremental future release. I will update the title. @monzug <https://github.com/monzug> if you can reproduce in another scenario, let's open a separate issue for that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#746?email_source=notifications&email_token=AJ32UOIY6PKOYLXQEI2UD5DQFZ5UDA5CNFSM4IKUMNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD443A6Y#issuecomment-523874427>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ32UOJXPCB6Q6VC2E7YNOLQFZ5UDANCNFSM4IKUMNCQ> .

[monzug]

I was able to repro the above scenario in the safari build (About Alpheios
Safari App Extension 3.0.0.65
Alpheios Components 1.2.39)
I changed the page language to greek and then I was not longer able to have the language changed to latin in the morphology pop-up. I had to scroll from Latin to Greek and then select Latin again from drop-down. Only from this moment, double-clicking on any Latin word did open the morphology pop-up.
see screenshot

[monzug]

to repro: go to https://scaife.perseus.org/reader/urn:cts:greekLit:tlg0096.tlg002.First1K-grc1:1-4b/
login as any user, double click on a couple of greek words, then log out. verify that page language is latin again. Activate Alpheios, then double click on ὑπὸ. You'll get the message that language is Latin, change language to Greek. close the button and double click to an other word such as ἐπώλει or δὲ with same error. now from the message, change the drop-down language from Greek to latin than Greek again. double click on any greek word. it will work fine now.

[monzug]

can't wait to test this one!!!

…

On Tue, Oct 1, 2019 at 1:59 PM Bridget Almas ***@***.***> wrote: Closed #746 <#746> via ecdebb6 <ecdebb6> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#746?email_source=notifications&email_token=AJ32UOMQ3YFSTIG3FPCH25LQMM3SNA5CNFSM4IKUMNC2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOT6F4WZA#event-2676738916>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ32UOOOU6ZFLWD7YGIV5G3QMM3SNANCNFSM4IKUMNCQ> .

[balmas]

qa 3.0.1.74/components 1.2.50

(crossing my fingers...)

[monzug]

I haven't been able to replicate this so far. Thanks Bridget!!!!

…

On Tue, Oct 1, 2019 at 2:29 PM Bridget Almas ***@***.***> wrote: qa 3.0.1.74/components 1.2.50 (crossing my fingers...) — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#746?email_source=notifications&email_token=AJ32UONEYAE45WVKLT2SM23QMM7CXA5CNFSM4IKUMNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEABCZDA#issuecomment-537013388>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ32UOKIIZFBILDCKJL7AQDQMM7CXANCNFSM4IKUMNCQ> .

[monzug]

still investigating this but in https://www.loebclassics.com/abstract/augustus-res_gestae/1924/pb_LCL152.345.xml?rskey=B19U2S&result=1&mainRsKey=fRpqMi
in which we have a mix of greek and latin text, no matter if page language is Greek or Latin, when I double click on any greek word, the change language pops-up and keeps asking to change to latin. if I select greek from drop-down, it does not set greek as language but it's still latin.

[monzug]

still looking for other reproducible scenarios

[balmas]

Ah, I got a little confused with this issue. The issue in the title of the bug is not fixed. I fixed the scenario when the language shown in the select box was different for some reason than the language used for lookup. But not the ability to override the underlying page language. That requires a bigger fix.

[monzug]

the one reported in the bug it has been fixed or at least I was not able to repro. not sure if this is a side effect of the fix, though. I am still trying to find other scenarios

…

On Wed, Oct 2, 2019 at 9:37 AM Bridget Almas ***@***.***> wrote: Ah, I got a little confused with this issue. The issue in the title of the bug is not fixed. I fixed the scenario when the language shown in the select box was different for some reason than the language used for lookup. But not the ability to override the underlying page language. That requires a bigger fix. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#746?email_source=notifications&email_token=AJ32UOKF7QDM6APH3O7FIQLQMSPX7A5CNFSM4IKUMNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAEYORQ#issuecomment-537495366>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ32UOMIYAXDCYFGPBXVIRLQMSPX7ANCNFSM4IKUMNCQ> .

[monzug]

so, I found an other text with mix of latin and greek words and change language works like a charm. text is at https://www.thelatinlibrary.com/gellius/gellius12.shtml

not sure what's the problem in https://www.loebclassics.com/abstract/augustus-res_gestae/1924/pb_LCL152.345.xml?rskey=B19U2S&result=1&mainRsKey=fRpqMi but change language does not work at all. @balmas? latin is sticky not matter if page language is Greek or Latin.

[balmas]

the problem with loeb is that it explicitly identifies the language of the text as 'la' and that takes precedence over the user preference. That's why this is really two separate issues.

Here's the source of the Loeb page

<section class="div1 language" lang="la">
...
<p>Μεθηρμηνευμέναι ὑπεγράφησαν πράξεις τε καὶ
δωρεαὶ Σεβαστοῦ θεοῦ, ἃς ἀπέλιπεν ἐπὶ Ῥώμης
ἐνκεχαραγμένας χαλκαῖς στήλαις δυσί.</p>
</section>

fixing this is more complicated than I can put in the incremental. The work around is to copy and paste the text from the page into the lookup and specify the language there.

[monzug]

finally I got it!!!! sorry for the confusion. so, the issue in Loeb is a different one. will enter a new issue for this so we keep record, no need to fix it but at least it's there!!! I did enter issue #830 for our record. Thanks.