In the first case, when I opened the Transclusion dialog (by clicking in the references section, where the template is used) the template description was shown (as expected). Typing one of the template parameters, I also get its label normally.

On the other hand, for the second link the user language (pt-br) was different from the content language (pt) and the user see no description and no labels.

So you'll need to prepare for some interface design to tell users that "Some
text written in English" and "Some other text written in Spanish" lines are
not in pt.

Why couldn't the TemplateData just be written in the users's language?

And the format of JSON needs to be modified to include this info.

I don't think that's a good outcome. If there isn't a description in your language (in this case, pt), we shouldn't magically tell you that we've given you a message in a different language (we don't do this for the MW messages framework, for instance).

(In reply to comment #7)
> (In reply to comment #5)
> > Fine technically - I think users would be upset and confused.
>
> So you'll need to prepare for some interface design to tell users that "Some
> text written in English" and "Some other text written in Spanish" lines are
> not in pt.

Why couldn't the TemplateData just be written in the users's language?

You can't expect all templatedata blocks to have labels in all hundreds of languages which MediaWiki supports.

> And the format of JSON needs to be modified to include this info.

I don't think that's a good outcome. If there isn't a description in your
language (in this case, pt), we shouldn't magically tell you that we've given
you a message in a different language (we don't do this for the MW messages
framework, for instance).

We do so in Wikibase, if the user indicates that they can read another language -- in our implementation it checks {{#babel: }} currently but some global preferences here will be nice of course.

I don't think that's a good outcome. If there isn't a description in your
language (in this case, pt), we shouldn't magically tell you that we've given
you a message in a different language (we don't do this for the MW messages
framework, for instance).

(In reply to comment #9)
> I don't think that's a good outcome. If there isn't a description in your
> language (in this case, pt), we shouldn't magically tell you that we've given
> you a message in a different language (we don't do this for the MW messages
> framework, for instance).

BTW this comment means WONTFIXing this whole bug.

Why?

This is just me saying that I don't think that instead of "Chien", if it doesn't exist in French we should give users "Dog -- OMG We gave you this message in English even though you asked for it in French!", which feels significant over-kill.

(In reply to comment #11)
> (In reply to comment #9)
> > I don't think that's a good outcome. If there isn't a description in your
> > language (in this case, pt), we shouldn't magically tell you that we've given
> > you a message in a different language (we don't do this for the MW messages
> > framework, for instance).
>
> BTW this comment means WONTFIXing this whole bug.

Why?

This is just me saying that I don't think that instead of "Chien", if it
doesn't exist in French we should give users "Dog -- OMG We gave you this
message in English even though you asked for it in French!", which feels
significant over-kill.

Then I guess your point is that pt-br and pt are more similar, so falling back from pt to pt-br is acceptable, while fr and en are not this case. However technically pt-br and pt have the same relationship as fr and en, or we'll have to compose some language similarity table ourselves, and manage to resolve many edge cases (eg. dialects).

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > I don't think that's a good outcome. If there isn't a description in your
> > > language (in this case, pt), we shouldn't magically tell you that we've given
> > > you a message in a different language (we don't do this for the MW messages
> > > framework, for instance).
> >
> > BTW this comment means WONTFIXing this whole bug.
>
> Why?
>
> This is just me saying that I don't think that instead of "Chien", if it
> doesn't exist in French we should give users "Dog -- OMG We gave you this
> message in English even though you asked for it in French!", which feels
> significant over-kill.

Then I guess your point is that pt-br and pt are more similar, so falling
back from pt to pt-br is acceptable, while fr and en are not this case.

Yes.

However technically pt-br and pt have the same relationship as fr and en,
or we'll have to compose some language similarity table ourselves, and manage
to resolve many edge cases (eg. dialects).

Oh. I assumed the jQuery.i18n (or one of the other JS, MW-independent tools that the Language Engineering team have built) would have this built in. Is that not the case?

(In reply to comment #6)
> So I'm not too Wikidata-savvy, but it seems this patch might be useful (if
> it's
> not, ignore me and carry on):
>
> https://gerrit.wikimedia.org/r/72867
>
> Right now there is no way to determine the real language of a message from
> the
> CDB cache. That patch changes this.

Not really. Labels and descriptions in TemplateData are stored in some JSON
blob in a customized format, rather than normal messages.

For now this is up to the client side to handle, which realistically means it won't be handled (current language > en > nothing).

For the future I intend to have the templatedata API take a parameter for language code and resolve it on the server side. For three reasons:

On wikis where there is more than 1 language commonly used (which is the whole point of this bug and where it is relevant, since if there is only 1 language, the wiki author can just specify { "description": "Text." } without lang-codes)..., on those wikis there will be more than 1 language defined. This will result in a large blob of JSON being transferred to e.g. VisualEditor for each template which is quite a lot of data.

Even so, it would then still require the client-side to have knowledge of all of this and process it. Which involves a lot of language data being send to the client, a lot of translations being sent to the client, and the then client having to do all the computation for it. We can solve this the same way we solved it in ResourceLoader; We'll still cache it, but fragment it by language code based on request context.

Also, this way we can provide good values for languages that don't exactly fallback but use a language converter. Which is also something that could potentially be done client side, but I don't see that happening just yet.

Also, this way we can provide good values for languages that don't exactly
fallback but use a language converter. Which is also something that could
potentially be done client side, but I don't see that happening just yet.

Which isn't really doable currently I guess; or it requires delivery of huge conversion tables (for Chinese).