Thanks, this seems to do the trick!

@cscott Seems that fix is not complete -- TOC is not honoring NOTC

ACTUAL:

ACTUAL:

Same for NOTC

In T424370#11856506, @Winston_Sung wrote:

We generally don't expect language converters to be disabled per-namespace.

In T242908#11857832, @Winston_Sung wrote:

T409621: Store display title in language variant in a page property

Note that this request is not going to work correctly all the time. In Serbian Wikipedia, articles can be named either in Cyrillic (90% of the time, this is the case) or in Latin.

BTW, NOCONTENTCONVERT does not work in Parsoid

I guess that script should be honored, author probably had some intention with it.

Case of ZH Wikipedia is not normative. Every Wikipedia should be allowed to have specific conversion experience.

Additionally, there should be option to still run conversion on a language of the host Wiki. For example, on Serbian Wikipedia, we would like to transliterate text marked as Serbian.

In T191571#11853297, @Djido wrote:

Additionally, is it possible that LanguageConverter skips text inside <span's which are marked as lang=xx (except if lang is sr, sr-*) ? That would help a lot as well.

In T191571#11853345, @Djido wrote:

Another request would be to just skip transliteration for talk pages? People are mixing both scripts there, and do not bother to insert -{..}- as necessary.

This is a long-time annoyance of mine. Basically, Serbian Wikipedia elected to use only Cyrillic names for categories. However, we still have a need for categories which contain Latin script in names, such as Latin nomenclature names (e.g. Категорија:Myrtales), band names (e.g. Категорија:The Beatles), or even mixed (e.g. Категорија:Албуми групе The Beatles).

Another request would be to just skip transliteration for talk pages? People are mixing both scripts there, and do not bother to insert -{..}- as necessary.

Additionally, is it possible that LanguageConverter skips text inside <span's which are marked as lang=xx (except if lang is sr, sr-*) ? That would help a lot as well.

There are some other templates/modules where we need to implement transcription prevention, but it is mostly good now.

I did some changes to SR Wikipedia, and I came to conclusion that we still can proceed with no detection of content.

I did some changes to SR Wikipedia, and I came to conclusion that we can proceed with no detection of content.

So, it is less alarming than it was initially.

I updated our Module:Lang and Module:URL to fix behavior when Parsoid is used. Only left is to try to fix Module:CS1, which still transliterated all the time. I can insert -{...}- there...

What is guessing provides? If we modify Module:Lang and Module:CS1 to insert non-converting marks (-{...}-) around all the text they insert into page, then simply running transliteration always would suffice -- Text outside -{...}- will just be transliterated (save for few heuristics, such as Roman numerals).

Yes, but without Parsoid, {{lang|en|...}} is not transliterated, nor is one inside {{cite... template. With Parsoid, everything is transliterated, which is wrong. What is responsible for the difference.

Basically, I would say that detection of content is totally irrelevant and unnecessary.

In T419328#11852541, @Hakimi97 wrote:

How about try these ones (I think I found another problem, which is the interface messages are not loaded according to language variant if nolcguess is activated):
https://sr.wikipedia.org/w/index.php?title=Џефри_Сакс&variant=sr-ec&nolcguess=1&useparsoid=1
https://sr.wikipedia.org/w/index.php?title=Џефри_Сакс&variant=sr-el&nolcguess=1&useparsoid=1

For Serbian Wikipedia, there should be no guessing at all, on any level.

@cscott, workaround ?nolcguess=1 does not work on Serbian Wikipedia. Turn on Parsoid and check out https://sr.wikipedia.org/wiki/Џефри_Сакс?nolcguess=1. Still messed up.

For Serbian Wikipedia, there should be no guessing at all. On Serbian Wikipedia, if user selects Cyrillic, it should transliterate to Cyrillic everything outside lang tags and -{...}- syntax. If article is written in sr-Cyril, it is no-op anyway to transliterate Cyrillic to Cyrillic.

There should be no guessing at all. On Serbian Wikipedia, if user selects Cyrillic, it should transliterate to Cyrillic everything outside lang tags and -{...}- syntax. If article is written in sr-Cyril, it is no-op anyway to transliterate Cyrillic to Cyrillic.

a) Logo contains Serbian national colors, which are common to all Serbs wherever they live, and it does not contain national flag of Serbia.
b) This is consistent with usage of Ukrainian national colors on Ukrainian Wikipedia, for last four years.

There is no consensus yet. Voting will be done in seven days.

Can we at least get option to publish to Draft namespace without restrictions? Essentially, this current workflow:

@Ladsgroup Our counts. on Serbian Wikipedia, are still broken. So fix was not applied everywhere?

Also, message (bold part) should be better at conveying what is wrong -- it says "Your translation contains 100% of unchanged text". My first instinct is to interpret that as if tool detected that I have _untranslated_ text (who bothers to read, gray, small text underneath? :) ).

Yeah, it is getting to the point that I would be served better by copy-pasting it into Google Translator, or even just manually translate. Tool with those restrictions seems rather non-useful to me.

Basically, you must superficially change machine translation, even if it good enough?

@SBisson, this is a new thing? I had no such problems before, and what if machine translation is good enough? It actually gotten much better, so not many manual intervention is needed.

Reason for this was that you were already told what is the issue: you haven't edited the machine translation enough.

Note that there is no untouched paragraphs, and there is barrely few English words (in original names). Yet, paragraphs which are 100% Serbian text, without any single Latin character, are marked as untranslated.

@Nikerabbit, you do not speak Serbian, but I assure you 100% of text is translated. Maybe not ideally, but tool cannot judge _quality_ of transation. It just claims that none of paragraphs are translated, and that 100% of text is not translated. Even without knowledge of Serbian you can see that it plain bug.

@Nikerabbit, how ist that 'enhancement' and low priority? I am reporting that tool is completely unusable for translating into Serbian -- I was not able to complete translations at all since the bug appeared.

Yeah, I am native speaker of Serbian as well :) Most of the text is just as-is from the translator tool. My workflow is to dump machine translation, correcting just most noticable errors, then go through Serbian article and fix it up, as output of the tool contains some quirks which I find more comfortable editing in the source editor (since translator tool just gives me this visual editor which is rather clumsy.

Example of translation flagged as "100%" not translated:

Message clearly says "100% of text is not translated". At least, there is a bug to imply that there is no translation at all. It does not say "100% of paragraphs are not translated".

I am not asking anybody to read Serbian -- there is a good-sourced information on English Wikipedia, in English language. It is simply rendering _exact_ same text, just using Calibri font (on Windows, I am not familiar with fonts on other platforms):

I do not think that we should ask for community consensus. It is just matter of using correct typography for Serbian language. More details can be found on English Wikipedia: