Ouch.

The problem is probably in ve.dm.Document.js, line 40.

I know little about the DM, so it may be a naive question, but is there a reason to set dir to ltr and lang to en by default?

In T71969#835633, @Amire80 wrote:

The problem is probably in ve.dm.Document.js, line 40.

I know little about the DM, so it may be a naive question, but is there a reason to set dir to ltr and lang to en by default?

IIRC the reason was "this looks difficult and makes my brain hurt, let's do something easy instead". And now we have this bug.

Fair enough :)

Can it be just set to nothing if not given as an argument? I just brutally removed these two lines, and it solved this particular problem, but it probably breaks something else.

It's probably better to read from some parent node, but I'm not sure what is The Right Way to do it in the VE API.

I've looked through the hierarchy of the surface and the document direction and language; it seems to me that it's a good idea to have the 'ltr' fallback, but the problem is that we don't seem to properly define the language when we create documents, which is especially important for SurfaceWidgets.

Since SurfaceWidgets are UI components, we should either rethink having them use the document model's "getLanguage" (the model usually reflects the wiki language rather than UI/User language) and instead have it look at the interface language.

I need to look at this more in depth before I change anything, and probably consult with Ed on how to make this work best.

FYI, I worked around it locally in the Hebrew Wikipedia's Common.css:

.ve-ui-mwMediaDialog .ve-ce-paragraphNode {
	direction: rtl;
}

But this is very ugly, and should be fixed properly.

In T71969#835775, @Mooeypoo wrote:

I've looked through the hierarchy of the surface and the document direction and language; it seems to me that it's a good idea to have the 'ltr' fallback, but the problem is that we don't seem to properly define the language when we create documents, which is especially important for SurfaceWidgets.

Since SurfaceWidgets are UI components, we should either rethink having them use the document model's "getLanguage" (the model usually reflects the wiki language rather than UI/User language) and instead have it look at the interface language.

I need to look at this more in depth before I change anything, and probably consult with Ed on how to make this work best.

Without having looked at this in detail, I think inheriting the document direction is likely to be more sensible than using the UI direction. Otherwise this bug just changes to "all SurfaceWidgets are LTR when I use English UI" (as well as "all SurfaceWidgets are RTL when I use Hebrew UI"). However, for best results I think we might need to compute the local direction (e.g. caption of image inside <div dir=rtl>) which is unfortunately a CSS operation. But the document direction would already be better than the UI direction I think, let alone hard-coded 'ltr'.

In T71969#836407, @Amire80 wrote:

FYI, I worked around it locally in the Hebrew Wikipedia's Common.css:

.ve-ui-mwMediaDialog .ve-ce-paragraphNode {
	direction: rtl;
}

But this is very ugly, and should be fixed properly.

You're probably marginally better off targeting .ve-ui-mwMediaDialog .ve-ce-documentNode instead, although that element does have a dir=ltr attribute, so you might need !important to do that.

Change 178899 had a related patch set uploaded (by Mooeypoo):
Image caption should have parent document direction

https://gerrit.wikimedia.org/r/178899

Patch-For-Review

Change 178899 merged by jenkins-bot:
Surfaces should have parent document direction

https://gerrit.wikimedia.org/r/178899

Thank you!