In T220415#5194765, @Lucas_Werkmeister_WMDE wrote:

Demo screenshot as of PS9:

In T208981#5193973, @Der_Keks wrote:

Just wanna ask if you could explain me the current status. I currently stuck on this problem while editing :)

In T223349#5191561, @matmarex wrote:

So there are two possible solutions:

1. The lazy one: Change the "cite-ve-othergroup-item" message to something less grammatically abhorrent, such as "Citation: $1" or "$1 (citation)".
2. The proper one: Add a separate message for each of the possible 6 options when it's used in the "Insert" menu rather than the "Cite" menu.

It's possible we can get rid of these messages entirely. It seems to be down to a config wgCiteVisualEditorOtherGroup = true, which I don't understand why we have at all. It might be a legacy thing we can get rid of?

In T222878#5171933, @cahyo.ramadhani wrote:

@Mvolz Ah, I see. I have added each template with TemplateData in the documentation. Could you please re-enable that so that I can try if it works?

The good news this only effects wikis with wgCiteVisualEditorOtherGroup = true, which as far as I can tell is only the case on mediawiki.org and not in any other wiki, including non of the Wikipedias.

@Esanders did this change recently I think?

Or perhaps we should have just refractored the existing keys in other
languages in the source...

Ah, that's not ideal - I'm afraid that's perhaps an issue with
translatewiki? Unfortunately it seems that if a key is changed, it's marked
for re-translation rather than moved.

They've just been renamed so they can just be copied over exactly... not
sure if that's what you're asking?

This is because it has been incorrectly configured; there is no template data in the cite web template. I've temporarily disabled it.

The cs1 module on en wiki recently changed to sniff these templates in the page. This is a better approach than doing it from inside ve anyway :).

Is there a way to at least disable the link on namespaces that aren't supported? It's pretty confusing to have the link there and have it be a dead link :).

In T98618#5135369, @Whatamidoing-WMF wrote:

So we'll end up with two systems:

1. The one currently on MediaWiki.org (no templates/no citoid/no nothing)
2. The one currently on most Wikipedias (templates+citoid) – the only difference being that for some of them, the "Automatic" tab will be grayed out.
   
   Right?

In T98618#5135180, @Whatamidoing-WMF wrote:

We have three systems:

1. no templates
2. templates but no citoid
3. citoid
   
   Will all of them move to this system?

Before change:
(Wikis with automatic tab disabled)

Ah never mind, looks like it'll make the cut without cherry picking?

In T216775#5093447, @Esanders wrote:

@Mvolz I've pushed this change to the test server.

Thanks!

In T216775#5084713, @Esanders wrote:

In T216775#5071948, @Mvolz wrote:

Awesome! There's a slight delay with no loading animation in between when the barcode app closes and when the isbn gets inserted that is just a little too long for no feedback on my phone... is there any way to make that pending? And also, when you press back after denying camera access, you get an empty dialog. But yes ship it :D.

Can you make a screen recording? The dialog should be closing fairly instantly - if it isn't that could be the shutdown code for the library causes the main thread to hang

In T219510#5082874, @dduvall wrote:

In T219510#5082854, @Mvolz wrote:

In T219510#5082803, @dduvall wrote:

@Mvolz I'm currently holding the group1 train deployment. Do you have an update or ETA on a fix?

I'm not 100% it's worth holding the train over - it'll disable citoid on at least one small language wiki. But the fix isn't done yet, no. Alternatively we can just revert it but note it requires reverting the change in the cite extension as well.

Thanks for the clarification. I'll proceed with group1 and check in tomorrow before promoting all wikis.

Also this won't affect group 1, only some wikis in group 2

In T219510#5082803, @dduvall wrote:

@Mvolz I'm currently holding the group1 train deployment. Do you have an update or ETA on a fix?

I've found an example of a Wikipedia where deploying the previous change without this fix will disable citoid, so I think it should be cherry picked to the previous cut once merged:

I checked this locally, and the merged change disables citoid even if the automatic tab is correctly configured. I don't think this is the correct behaviour; if neither are configured, it should be de-registered, but not cite tools missing alone: it should also check that Mediawiki:Citoid-template-type-map.json doesn't exist as well.

Both zotero and citoid can't verify the https certificate but the browser can: https://github.com/zotero/translation-server/issues/101

I've now deployed a fix that no longer splits the authors, and just puts them all in the "last" field. So in terms of how it's rendered with most citation templates, it looks a lot better. However this is a bit hacky, so I'm leaving this open for right now. It will continue to leave in parts of the author name that we don't necessarily want, like the birth date in parens.

Citoid no longer split names by default. But in the particular case you mention, you'll still see the same result, as zotero does this and I think it's not possible to change their minds about this as default behaviour, so I guess in that sense it's also partially declined...

In T124610#5072783, @Izno wrote:

This looks a lot like T132288: Create tool to identify plain references and offer a fix.

Awesome! There's a slight delay with no loading animation in between when the barcode app closes and when the isbn gets inserted that is just a little too long for no feedback on my phone... is there any way to make that pending? And also, when you press back after denying camera access, you get an empty dialog. But yes ship it :D.

Step 1:

In T218564#5069366, @Nikitrain wrote:

when I see qqq.json it already has
"citoid-citefromiddialog-search-placeholder": "{{doc-important|Do not translate example.com as it is a domain name specifically reserved by IANA for examples.}}\n\nPlaceholder for the URL/DOI/PMCID/PMID/ISBN search field.",
Should I still edit the message.

In T218564#5069343, @Nikitrain wrote:

In T218564#5069340, @Mvolz wrote:

In T218564#5069284, @Nikitrain wrote:

@Mvolz I have opened a pull request.
and include this note at the end of the qqq.json file
/*
Note for translators: Do not translate the search-placeholder domain name ("http://www.example.com").
http://www.example.com is a reserved domain intended to be used as a placeholder and should not be translated.
*/

Thanks for the feedback! on it ! is anything else needed to be done other than this?
It should go in the message in qqq, not as a comment. But the text is fine (although you don't need the note for translators bit as this is implied, since qqq is basically a file with notes for translators!)

In T218564#5069284, @Nikitrain wrote:

@Mvolz I have opened a pull request.
and include this note at the end of the qqq.json file
/*
Note for translators: Do not translate the search-placeholder domain name ("http://www.example.com").
http://www.example.com is a reserved domain intended to be used as a placeholder and should not be translated.
*/

In T218564#5069257, @Mvolz wrote:

In T218564#5069255, @Nikitrain wrote:

Seeing the jv.json file on git hub. I noticed that file contain
"citoid-citefromiddialog-search-placeholder": "conto http://www.example.com",
instead of
"citoid-citefromiddialog-search-placeholder": "http://www.example.com",
Is this how this is needed to be fixed?

Oh. it looks like someone already fixed it! In that case just the qqq message needs to be fixed.

In T218564#5069255, @Nikitrain wrote:

Seeing the jv.json file on git hub. I noticed that file contain
"citoid-citefromiddialog-search-placeholder": "conto http://www.example.com",
instead of
"citoid-citefromiddialog-search-placeholder": "http://www.example.com",
Is this how this is needed to be fixed?

In T218564#5069222, @Nikitrain wrote:

I am interested in this task. One query, Where should the Note be included, in the beginning, end or someplace else?

@Jdforrester-WMF you said elsewhere this was resolved?

This is now deployed.