I'm certainly open to other ideas, but right now we've tried options and this was the best one to go with at the moment. Perhaps @tstarling has some ideas but what I know from our work:

• T97922 is the same issue as this in the end
• setlang= (what ULS uses) does not work with SecurePoll (I do not know why)
• The reason for the "en" tags ( T97922 ) is because the wiki itself is en but when uselang is set anything translated on the page changes.
• There is no common.js or gadgets etc on voteWiki for security reasons (to stop javascript from reading a vote for example).
• I don't think connecting it to CentralAuth is either a good idea or likely to fix the issue given the setlang problem.
• In the past language was set based on what wiki you were coming from, however sending people back to their most active wikis to vote caused a lot of issues and a lot of complaints and seemed to confuse and lose a lot of voters. Even highly experienced wikipedians were lost and couldn't find out how to vote without asking for help.
  • Because of this the system was changed to allow everyone to vote through meta, and to vote from 1 link so that we could send everyone through that one link or big button. I think this was a good change.
  • A side effect of that was that it appears that there is no good way to set the language for the user as they go into securepoll like there used to. @tstarling or someone may have an idea on how to do that if we pass a language parameter with a user when they click the banner or button or something. Right now they can see what was done to grab language in the securepoll section of https://noc.wikimedia.org/conf/CommonSettings.php.txt.
• The languages we initially added to the language switcher were just the ones we already had full or close to full translations for. Obviously we could add more (and I know I'm happy too, I image the committee is) but I expect that doesn't necessarily ease your concerns.

Right now I think the ease of getting to the vote outweighs the (not insignificant) clunkiness of the translation. If anyone has ideas on how to pass the language correctly to securepoll I'd really love to hear it (someone smarter with mediawiki then me might get a sense from looking at the current setup in CommonSettings and how it is passed to the system) because that would likely help many of these problems since we could pass the language of the wiki or their current language along when they click links to vote.

I agree that there is room for improvement in the future. However, given a couple of weeks to prepare, I am not sure that much else could have been done this year.

A few thoughts:

• I do not support the idea of enabling javacript or CentralAuth on VoteWiki as it is intentionally meant to be a more tightly controlled and secure platform.
• In a perfect world - yes - absolutely - we would have translations in hundreds of languages. However, the reality is that we had about 48-72 hours to translate paragraphs of text - and doing so in hundreds of languages in that timespan was not really an option this year for a long list of reasons. Keep in mind that the translation need to be manually entered into SecurePoll as it does not really interface with Translate extension - which is not installed on VoteWiki right now anyway.
• Ease of getting to vote will likely continue to outweigh simplicity in translation. Sadly, it is unlikely that will be addressed in time for this election - and will likely require a lot more thought on how to better integrate the various extensions that VoteWiki uses.

Again, I think we are absolutely open to ways of doing this better. However, I am not sure there are actionable steps the committee can take at this moment. If engineering or tech volunteers are interested in working on the problem more long-term - that would be fantastic. If there are some other simple solutions to implement, I think that would be great. However, the suggestions so far offered do not seem immediately possible in my opinion.

I gave two very actionable steps other than the one which you rejected.

In T97923#1255187, @Nemo_bis wrote:

I gave two very actionable steps other than the one which you rejected.

Can you point them out? I don't think that any of them would work with my understanding from our testing earlier and so perhaps I wasn't clear.

• I don't think allowing ULS to be used by anons helps because ULS uses setlang= which does not translate the SecurePoll content.
• I don't think we should connect it to CentralAuth (especially at such a late notice) since it was locked down for what I consider good security reasons. I'm also not sure it would actually help for this particular issue for the same setlang issue with SecurePoll. Switching my interface language (as a user on voteWiki) does not work
• There is no common.js, gadgets etc to use the language selector you mention.

I don't think allowing ULS to be used by anons helps because ULS uses setlang= which does not translate the SecurePoll content.

It does: uselang alters the content, which means the content is respecting interface language; setlang only alters interface language, in ULS. Using ULS is obviously the ideal solution.

There is no common.js, gadgets etc to use the language selector you mention.

Ok, wgUseSiteJs is false. I see no compelling reason to keep it so, if setting it to true is needed to fix this bug. editinterface is already restricted to election committee and few others, who have access to way more sensitive data on this wiki.

In T97923#1255223, @Nemo_bis wrote:

Ok, wgUseSiteJs is false. I see no compelling reason to keep it so, if setting it to true is needed to fix this bug. editinterface is already restricted to election committee and few others, who have access to way more sensitive data on this wiki.

It seems unlikely that is going to be done for this election, as James said:

There is no common.js or gadgets etc on voteWiki for security reasons (to stop javascript from reading a vote for example).

At the very least, it would require some input from Ops and Security on any security implications.

In T97923#1255223, @Nemo_bis wrote:

I don't think allowing ULS to be used by anons helps because ULS uses setlang= which does not translate the SecurePoll content.

It does: uselang alters the content, which means the content is respecting interface language; setlang only alters interface language, in ULS. Using ULS is obviously the ideal solution.

I would agree with this if it would work to be honest, but I'm saying that as a logged in user I change language in ULS and only the interface text changes. The securepoll content (the translated summaries, intro etc) does not change. I've just tried this out a bunch of times and while the font changes to fit what would be expected in that language the text is still in English (compared to with uselang= where it changes to the expected language where translated). This is clearly not what SHOULD happen, but it is definitely what is happening.

SecurePoll determines the user's language as part of session transfer from the jump page. The remote wiki (votewiki) calls back to an internal entry point on the source wiki (auth-api.php) and fetches the user's information via HTTPS. So whatever user language the user has set in their preferences on metawiki will be the one that is seen on votewiki.

You can't use ULS or setlang or CentralAuth or whatever on votewiki because votewiki does not use the local user's language for displaying the vote. It uses the language of the user on the source wiki. So an obvious hack would be to inject a language selector into the jump page on metawiki, which changes the user's preferences prior to transferring the session to votewiki.

Thanks Tim, two quick questions.

In T97923#1255951, @tstarling wrote:

SecurePoll determines the user's language as part of session transfer from the jump page. The remote wiki (votewiki) calls back to an internal entry point on the source wiki (auth-api.php) and fetches the user's information via HTTPS. So whatever user language the user has set in their preferences on metawiki will be the one that is seen on votewiki.

Are there any changes we need to make to the Common Settings setup to make this work? Right now it seems to be getting it from the wiki language because when I change my user language on meta I still get English on SecurePoll (even when doing so logged out from voteWIki).

You can't use ULS or setlang or CentralAuth or whatever on votewiki because votewiki does not use the local user's language for displaying the vote. It uses the language of the user on the source wiki. So an obvious hack would be to inject a language selector into the jump page on metawiki, which changes the user's preferences prior to transferring the session to votewiki.

This could work, I imagine we could also put a ?setlang=LOCALLANG into the url when they click the banner etc from a non En wiki which could help (it could be more annoying for people who don't want their language set, but I'm willing to consider it).

In T97923#1255965, @Jalexander wrote:

Thanks Tim, two quick questions.

In T97923#1255951, @tstarling wrote:

SecurePoll determines the user's language as part of session transfer from the jump page. The remote wiki (votewiki) calls back to an internal entry point on the source wiki (auth-api.php) and fetches the user's information via HTTPS. So whatever user language the user has set in their preferences on metawiki will be the one that is seen on votewiki.

Are there any changes we need to make to the Common Settings setup to make this work? Right now it seems to be getting it from the wiki language because when I change my user language on meta I still get English on SecurePoll (even when doing so logged out from voteWIki).

You would have to clear your votewiki session cookie. When a SecurePoll session is established, the user properties are inserted into the securepoll_voters table, and the linked ID is stored in the session. There are two securepoll_voters rows for you at the moment, both have language=en.

You can't use ULS or setlang or CentralAuth or whatever on votewiki because votewiki does not use the local user's language for displaying the vote. It uses the language of the user on the source wiki. So an obvious hack would be to inject a language selector into the jump page on metawiki, which changes the user's preferences prior to transferring the session to votewiki.

This could work, I imagine we could also put a ?setlang=LOCALLANG into the url when they click the banner etc from a non En wiki which could help (it could be more annoying for people who don't want their language set, but I'm willing to consider it).

Sure, if you like.

In T97923#1255972, @tstarling wrote:

In T97923#1255965, @Jalexander wrote:

Thanks Tim, two quick questions.

In T97923#1255951, @tstarling wrote:

SecurePoll determines the user's language as part of session transfer from the jump page. The remote wiki (votewiki) calls back to an internal entry point on the source wiki (auth-api.php) and fetches the user's information via HTTPS. So whatever user language the user has set in their preferences on metawiki will be the one that is seen on votewiki.

Are there any changes we need to make to the Common Settings setup to make this work? Right now it seems to be getting it from the wiki language because when I change my user language on meta I still get English on SecurePoll (even when doing so logged out from voteWIki).

You would have to clear your votewiki session cookie. When a SecurePoll session is established, the user properties are inserted into the securepoll_voters table, and the linked ID is stored in the session. There are two securepoll_voters rows for you at the moment, both have language=en.

Aha, thank you. With that info I was able to make it work pretty easily ;).

I'm discussing with a couple members of the committee some short and medium term techniques to make this better now.

In T97923#1256027, @Jalexander wrote:

I'm discussing with a couple members of the committee some short and medium term techniques to make this better now.

For now I have implemented a change in the banners so that clicking on them passes through the users language to be set & used for the jump page and SecurePoll. Will look into doing a choose your language drop down for others on the jump page tomorrow.

@Nemo_bis: "The manual language selector for 18 languages is clunky and unfair for the 330+ MediaWiki languages not listed."

Where were you seeing this? Was it on VoteWiki or the jump page? I'm not seeing anything like this in my dev set-up on Vagrant.

In T97923#1529089, @Fhocutt wrote:

@Nemo_bis: "The manual language selector for 18 languages is clunky and unfair for the 330+ MediaWiki languages not listed."

Where were you seeing this? Was it on VoteWiki or the jump page? I'm not seeing anything like this in my dev set-up on Vagrant.

That was a hack we put in to the top of the voteWiki page. It was just a template ( https://vote.wikimedia.org/wiki/Template:ElectionLang ) transcluded on the top of the ballot.

Understanding that this task has been without comment for seven years ... would this be considered solved with the implementation of T108756?