--- Comment #7 from Kunal Mehta (Legoktm) <> ---
(In reply to comment #5)
> Progress?

Not much, I had been waiting on most the internal refactoring to get merged
before picking this up. That's been done now so I'll take a stab at this again.

(In reply to comment #6)

> How will this handle incomplete translations? E.g. it could post
> * all existing translation pages including partial ones (maybe not such a
> good
> idea)
> *or only those at 100% (there may be problems with bug 47864 though) 
> *or only those whose status has been set to "published" (analogous to what
> CentralNotice does)

Right now the code just looks for a /langcode subpage and will use it if it
exists, regardless of the translation status. I think this can be
disadvantageous if there's a situation where there is an empty translation for
the specific language, but the next fallback has a complete translation.

I'm not very familiar with how the "published" status works. Do translation
admins set that? Is it commonly used?

We could do something like a percentage threshold, so if the status is above
80% (or some other arbitrary number) to use it.

> BTW, regarding "automagically": Notice that the existing solution which
> relies
> on {{CONTENTLANG}} doesn't quite deal with the language village pumps on the
> multilingual projects on Commons and Wikidata (where {{CONTENTLANG}} = en).
> Examples are [[commons:Project:Café]] (in
> [[m:Distribution_list/Global_message_delivery/es]])
> or [[d:Project:Warung Kopi]] (in
> [[m:Global_message_delivery/Targets/Tech_ambassadors]]). It may be too much
> to
> demand from this bug to fix the way Commons and Wikidata handle their
> multilinguality, but one should be aware of this limitation.

Yeah, I don't think those cases can be easily handled until bug 9360 is solved.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to