Page MenuHomePhabricator

words are often broken in the middle in Wikifunctions composition view
Closed, ResolvedPublicBUG REPORT

Description

Words are often broken in the middle in Wikifunctions composition view. See the following screenshots from https://www.wikifunctions.org/view/en/Z32836 , for an example:

Desktop Firefox:

תמונה.png (743×466 px, 70 KB)

Same page on the same computer in desktop Chrome:

תמונה.png (739×508 px, 76 KB)

Not the word "demonym": it appears differently, but is broken in both.

I also tried it with Arabic on the same page:

תמונה.png (758×551 px, 67 KB)

The reason I tried Arabic is that its script is cursive and particularly sensitive to wrong word breaks. The line breaking was in rather unexpected places:

  • A new line begins between the words ويكي (wiki) and بيانات (bayanat [data]), even though there is a lot of space after ويكي. (To clarify, in Arabic, there is supposed to be a space between "wiki" and "data". What's wrong about this is that I'd expect the line to be broken much later, in the middle of the next function name. This probably happens because these are the last two words in the name of this function, and the browser treats the whole name of the next functon as a string that shouldn't be broken, or something along these lines.)
  • The word لغة (lu3a [language]) in the end of the composition is broken in the middle, which is not supposed to happen at all.

It's hard to give totally predictable instructions to reproduce, because it probably depends a lot on the browser, the OS, the installed fonts, the customizations, the zoom level, the window size, etc. But I see it on a lot of pages.

Just a wild guess: This may be happening because the function names are not, as I would expect, in <span>s with actual space characters between them, but in a mix of <div>s and <span>s with spacing (probably) added by CSS and not by whitespace characters.

Event Timeline

Restricted Application added a subscriber: alaa. · View Herald TranscriptApr 1 2026, 5:04 PM

These are indeed a lot of spans that have a variety of classes which do things like : word-break: break-word and white-space: pre-wrap. where it breaks also depends on the width of the screen

I highly doubt there is a css fix that will fix this for all languages and screensizes and all use cases everywhere. We can also reconsider the entire span'ed approach but that is a bigger task.

Even in english it breaks in weird ways because we need a way to make texts not overflow the box while retaining some rules about what should stay together:

Screenshot 2026-04-08 at 20.34.34.png (796×474 px, 85 KB)

What happens if we don't break words is:

Screenshot 2026-04-08 at 20.35.57.png (848×442 px, 86 KB)

I will try to see if there is a way to make this better or not. I recall we worked on this component a lot of times in the past and we tried to fix a lot of displaying issues. I would need to make sure I don't break any of the fixes cases again.

These are indeed a lot of spans that have a variety of classes which do things like : word-break: break-word and white-space: pre-wrap. where it breaks also depends on the width of the screen

I highly doubt there is a css fix that will fix this for all languages and screensizes and all use cases everywhere. We can also reconsider the entire span'ed approach but that is a bigger task.

Yes, reconsidering the <span>-only approach is probably the right thing to do everywhere. In general, spaces should be added using the good old natural method—whitespace characters. Unicode is designed to handle them well. Adding visual space using only CSS without whitespace characters often causes various issues in display, and also in interaction clicking, selecting, and so on.

Even in english it breaks in weird ways because we need a way to make texts not overflow the box while retaining some rules about what should stay together:

Screenshot 2026-04-08 at 20.34.34.png (796×474 px, 85 KB)

I guess that there's screenshot here, and I can't see it, but yes, it's broken in English—that's how I first noticed it.

Change #1269412 had a related patch set uploaded (by Daphne Smit; author: Daphne Smit):

[mediawiki/extensions/WikiLambda@master] Fix ZObjectToString wrapping

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

I did a bunch of changed and I tested it with the page you mentioned and there it now looks ok I think: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1269412
I do need to test with a bit more content perhaps.

Some screenshots from local:

Screenshot 2026-04-09 at 13.45.00.png (1,000×830 px, 100 KB)
Screenshot 2026-04-09 at 13.45.18.png (974×830 px, 120 KB)
Screenshot 2026-04-09 at 13.45.29.png (836×854 px, 126 KB)

Others:

Screenshot 2026-04-09 at 13.47.09.png (974×950 px, 187 KB)
Screenshot 2026-04-09 at 13.48.23.png (688×1,304 px, 218 KB)
Screenshot 2026-04-09 at 13.48.08.png (976×1,098 px, 226 KB)
Z31700Z29823Z29823

I downside of the Patch is that it does not use break-word anymore, so I am a bit unsure with long names if it would cause issues.
tested a bit and not a lot of issues. we can perhaps try it out.

Screenshot 2026-04-09 at 13.55.41.png (954×966 px, 196 KB)
long names

I did a bunch of changed and I tested it with the page you mentioned and there it now looks ok I think: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1269412
I do need to test with a bit more content perhaps.

Some screenshots from local:

Screenshot 2026-04-09 at 13.45.00.png (1,000×830 px, 100 KB)
Screenshot 2026-04-09 at 13.45.18.png (974×830 px, 120 KB)
Screenshot 2026-04-09 at 13.45.29.png (836×854 px, 126 KB)

The words here are not broken, so it's good.

However, it looks like there is no space at all after the commas, which makes reading not fun. There should be a space after the commas (and again, it should be an actual space character).

There is also no space before the opening parentheses in those screenshots. This is different from the current situation in production, where I do see space before the parentheses. However, perhaps there really shouldn't be space there because that's the usual practice in math and programming is not to write a space before opening parentheses.

Others:

Screenshot 2026-04-09 at 13.47.09.png (974×950 px, 187 KB)
Screenshot 2026-04-09 at 13.48.23.png (688×1,304 px, 218 KB)
Screenshot 2026-04-09 at 13.48.08.png (976×1,098 px, 226 KB)
Z31700Z29823Z29823

I downside of the Patch is that it does not use break-word anymore, so I am a bit unsure with long names if it would cause issues.
tested a bit and not a lot of issues. we can perhaps try it out.

Screenshot 2026-04-09 at 13.55.41.png (954×966 px, 196 KB)
long names

I don't see those screenshots.

Change #1269412 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Fix ZObjectToString wrapping

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

This comment has been deleted.

Arg Phabricator makes me upload files and then needing to attach them again and grant permission..I keep finding this a bit annoying.
Ah yeah the spaces got lost. I can confirm — the <span> </span> content is getting stripped by Vue template whitespace condensation. I’ll switch separators to dynamic text bindings from script state, which Vue won’t trim away.

But making it an actual space make it that a sentence can be broken where the ( bracket of a function can be on a new line and the function on the previous line, making it also very unreadable:

function 
( some arg

After some more digging I came up with: (and ill make sure to attach the images this time;))

Screenshot 2026-04-14 at 11.34.11.png (880×362 px, 77 KB)
Screenshot 2026-04-14 at 11.35.09.png (538×756 px, 95 KB)
Screenshot 2026-04-14 at 11.35.22.png (434×824 px, 91 KB)
Screenshot 2026-04-14 at 11.35.48.png (898×324 px, 65 KB)
Screenshot 2026-04-14 at 11.36.06.png (550×536 px, 69 KB)
Screenshot 2026-04-14 at 11.36.11.png (476×626 px, 71 KB)

The problem with this solution is that it wont break words anymore, and therefor if we provide very long inputs that dont contain spaces we get a very malformed ui.

Screenshot 2026-04-14 at 11.38.52.png (2,636×346 px, 134 KB)

So before we just broke all words. I can attach a js handler to count character and then break but that is not really responsive to many screensizes.

Css is not aware of what it should break and what not. I think Ill revert the patch and give it a bit more thought.

Change #1270875 had a related patch set uploaded (by Daphne Smit; author: Daphne Smit):

[mediawiki/extensions/WikiLambda@master] Fix composition line wrapping and separator spacing in ZObjectToString

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

Change #1270876 had a related patch set uploaded (by Daphne Smit; author: Daphne Smit):

[mediawiki/extensions/WikiLambda@master] Fix composition line wrapping and separator spacing in ZObjectToString

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

Change #1270875 abandoned by Daphne Smit:

[mediawiki/extensions/WikiLambda@master] Fix composition line wrapping and separator spacing in ZObjectToString

Reason:

weird ai stuff

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

Change #1270876 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Fix composition line wrapping and separator spacing in ZObjectToString

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

I feel like some things are off in rtl now. Ill create a new ticket or make a new patch

@Amire80 Can you verify that this display is correct.

Screenshot 2026-04-16 at 16.32.48.png (894×350 px, 66 KB)
Screenshot 2026-04-16 at 16.37.19.png (900×352 px, 65 KB)
with i18n commawithout i18n comma

Because I am a bit unsure of some stuff:

  • in general function notation like this; should even be rtl to begin with?
  • () brackets this way. but think the browser does this so should be ok.
  • order of params in a function. I now used some css unicode-bidi:embed to make sure the first param is actually first so (param3, param2, param1)function, otherwise the browser would make the order very strange. Is this correct?
  • comma seperator; should that always be a comma like (,) or should it be replaced by the i18n comma-seperator (e.g. ، in Arabic):

Change #1272743 had a related patch set uploaded (by Jforrester; author: Daphne Smit):

[mediawiki/extensions/WikiLambda@master] ZObjectToString: Add bidi isolation for RTL rendering

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

Change #1272743 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] ZObjectToString: Add bidi isolation for RTL rendering

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