Problem with Afrikaans hyphenation dictionary
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox130 | --- | fixed |
People
(Reporter: danielgillespie717, Assigned: jfkthame)
Details
Attachments
(3 files, 1 external file)
Screenshot 2024-07-05 020939.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0
Steps to reproduce:
I'm using the GTranslate plugin on a WordPress site to translate content.
Actual results:
One of my menu items is "Community Support" which in Afrikaans translates to "Gemeenskapsondersteuning". I'm using hyphens: auto in CSS so it should hyphenate the word as it overflows its container but it doesn't.
Expected results:
Chrome and Edge correctly hyphenate the word to "Gemeenskapson-dersteuning". Firefox should do the same. The problem doesn't appear to be with the translation plugin since Firefox correctly hyphenates other words. The problem would therefore seem to be with the hyphenation dictionary for Afrikaans.
|
Reporter | |
Comment 1•2 years ago
|
||
An additional problem is that the translated version of "Local Information" which becomes "Plaaslike inligting" gets hyphenated when it doesn't need to. Firefox renders it as "Plaaslike inlig-ting" when "inligting" would easily fit in the container.
|
||
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
Assignee | |
Comment 3•2 years ago
|
||
By default, Firefox avoids hyphenating Capitalized words, because these are often proper names where hyphenation may be undesirable. (See bug 1550532 for the origin of this behavior.)
You can override this for Afrikaans (which may be a good idea, if it often has very long compound words) by going to about:config and creating a new Boolean pref named intl.hyphenate-capitalized.af with the value true. (This is set by default for German and Finnish; possibly Afrikaans should be added by default as well.)
The unexpected hyphenation mentioned in comment 1 does seem odd, but may be a result of something in the page's styling. Can you provide the address of the specific page where you're seeing this, or attach a standalone example that demonstrates it? Thanks!
|
|
Reporter | |
Comment 4•2 years ago
|
||
Linguistically the closet languages to Afrikaans are Dutch and German. They both have the same habit of joining English words together to form very long words. Firefox doesn't seem to have a problem hyphenating such words in Dutch and German, even if they are capitalised.
I'm unable to provide a URL for the website I'm working on as it has not yet been deployed and I don't currently have anywhere I can deploy it. While the about:config solution might work for me, it's not reasonable to expect every user of a website to implement such a fix. If that is the source of the problem then I would agree with you that it should be set by default.
I'm relative new to web development so I'm not exactly sure what you meant by attaching a standalone example. I assume you mean a webpage that illustrates the problem so I have attached a simple html file that has a similar menu to the one I am working on which exhibits the same problem. When viewed in Chrome or Brave "Gemeenskapsondersteuning" hyphenates correctly to "Gemeenskapson- dersteuning". When viewed in Firefox or Edge it does not hyphenate.
From my standpoint as a web developer, a webpage should display the way that I intend it to display, not the way a browser "thinks" it should display. Because the browser doesn't understand the context of what's being presented. In terms of hyphenation, I think it's worse for a word to not hyphenate and overflow its container than it is for it to hyphenate at an undesirable location in the word. This is especially true in menus where the width allocated to a menu item is often limited. "Hyphens" is an optional property that someone adds specifically because they want a particular behaviour. For a browser to elect to not hyphenate when it has been specifically asked to seems like an odd default behaviour and not what the average person would expect it to do.
If I've misunderstood what you meant by "standalone example" if you could please provide a brief explanation of what you require and I will do my best to provide it. In the example I've attached both "Gemeenskapsondersteuning" and "Noodprosedures" overflow their containers. It's less obvious that "Noodprosedures" is doing it but it's intruding into the tile's padding. The example from Comment 1 ("Plaaslike Inligting") doesn't seem to incorrectly hyphenate it in the example I've attached. But even in the actual website I'm working on it doesn't always do it incorrectly. Sometimes it does, sometimes it doesn't, and sometimes it does but then fixes itself after a couple of seconds. Which is very odd. But I'm less worried about things hyphenating when they shouldn't than I am about them not hyphenating when they should.
|
|
Reporter | |
Comment 5•2 years ago
|
||
|
|
Assignee | |
Comment 6•2 years ago
|
||
Thanks for the example, that's helpful to experiment with.
Given the tendency to have quite a lot of long words in Afrikaans (and similarly in Dutch), I'm inclined to think we should enable hyphenation of capitalized words for these languages by default (so you wouldn't have to make a local about:config change to get it). That should avoid the overflowing items in your example.
Note, though, that the breaks that are chosen won't always be the subjectively "best" option; the browser will use the last potential hyphenation position (based on the Afrikaans rules) on each line, where compound words like this might often be better broken at an earlier place. E.g. I'm seeing it break "Kennisgewings" as "Kennisge-wings", whereas I suspect "Kennis-gewings" would be preferable.
As an author, you might want to consider putting explicit "soft hyphens" (HTML ­) at the most logical break points for compound words like this; then these will be preferred over the automatic hyphenation positions that the browser finds throughout the word.
|
|
Assignee | |
Comment 7•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 8•2 years ago
|
||
From a purely practical point of view, the other thing I notice in experimenting with your example is that neither Safari nor Chrome seem to implement hyphenation for Afrikaans at all. So for a better result across all browsers, adding manual soft-hyphens to your menu items may be worthwhile.
|
|
Assignee | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 10•2 years ago
|
||
(In reply to Jonathan Kew [:jfkthame] from comment #6)
Thanks for the example, that's helpful to experiment with.
Given the tendency to have quite a lot of long words in Afrikaans (and similarly in Dutch), I'm inclined to think we should enable hyphenation of capitalized words for these languages by default (so you wouldn't have to make a local about:config change to get it). That should avoid the overflowing items in your example.
Note, though, that the breaks that are chosen won't always be the subjectively "best" option; the browser will use the last potential hyphenation position (based on the Afrikaans rules) on each line, where compound words like this might often be better broken at an earlier place. E.g. I'm seeing it break "Kennisgewings" as "Kennisge-wings", whereas I suspect "Kennis-gewings" would be preferable.
As an author, you might want to consider putting explicit "soft hyphens" (HTML
­) at the most logical break points for compound words like this; then these will be preferred over the automatic hyphenation positions that the browser finds throughout the word.
My situation is complicated by the fact that I'm building the website in English but the client requires it to be translated into a range of other languages dynamically using a WordPress plugin (GTranslate). As such, I can't directly add soft hyphens to the menu item titles because even if I do that for the English titles GTranslate will just remove them when it translates them. I have implemented a function within WordPress that will add soft hyphens to the words that are overflowing their containers but it's not a particularly robust solution. The client is experienced with using WordPress for their main website so they have an expectation that they will be able to add pages and rename pages as they require. This means they could add a page or rename a page to something that then overflows its container when translated. This would require the words to be added to the word array in the WordPRess function. Obviously I don't want the client going anywhere near the WordPress function files so myself or someone else will have to do that for them. So it's not a robust solution in that it doesn't solve the problem generally. So I agree with you that I think the best way forward is for Afrikaans and Dutch to allow hyphenation of capitalised words as this would solve the problem generally.
However, that being said, I think there's an issue with the hyphenation dictionaries for Afrikaans, Dutch, and also German (which has the same habit of joining English words into very long words when translated). In German, for example, Firefox allows hyphenation of capitalised words but then it hyphenates words when it doesn't need it. I'll upload a version of the stand alone example in German so you can see what I mean. It will hyphenate "Nachbar" in "Ein guter Nachbar sein" when it could just wrap it. It does the same thing with "Reparaturen" in "Wartung & Reparaturen". The difference between Firefox's and Chrome's approach to hyphenation, at least in regards to these languages, seems to be that Chrome only ever hyphenates a word if it is wider than its container whereas Firefox will hyphenate a word that is narrower than its container. I think that's the wrong approach to take since hyphenation is fundamentally an x-axis issue and page layouts are typically constrained along the x-axis but not the y-axis (because a page can only be as wide as the screen it's displayed on without generating an x-axis scrollbar which is generally pretty undesirable). Containers housing text can typically grow along the y-axis so that their contents don't overflow but they typically don't have the option of growing along the x-axis to prevent overflow, hence the need for hyphenation in the first place. I don't know whether the issue with words hyphenating when they don't need to is limited to specific languages or whether it is due to the overall approach that Firefox has taken to hyphenation as I can see the same issue in some other languages (e.g. French.) but not others (e.g. Polish).
|
|
Reporter | |
Comment 11•2 years ago
|
||
|
||
Comment 12•2 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 13•2 years ago
|
||
(In reply to Daniel Gillespie from comment #10)
My situation is complicated by the fact....
Ah, I see - yes, that definitely makes the manual soft-hyphen option more difficult to manage.
In German, for example, Firefox allows hyphenation of capitalised words but then it hyphenates words when it doesn't need it. I'll upload a version of the stand alone example in German so you can see what I mean. It will hyphenate "Nachbar" in "Ein guter Nachbar sein" when it could just wrap it....
I think you'll find that the same thing can happen in Chrome. That's just how hyphenation and line-breaking typically works: if hyphenation is enabled, each potential hyphen position is now a legitimate line-break, and the browser will fit as much content onto the line as it can, using whatever line-break opportunity (whether space or hyphenation position) is the last available. You may see slightly different results between browsers because of differences in precise font measurements or other factors, but for example, when I load your German example I see the same break in "Nach-bar" in Chrome on macOS as I see in Firefox. It's true that the entire word "Nachbar" could be wrapped to the second line, and that would be aesthetically better, but the fragment "Nach-" fits on the first line and so it is placed there.
It would be nice to have more detailed control of exactly how/where hyphenation gets used, and ways to prioritize certain line-breaks over others that are less desirable but can still be used if necessary. There are some additional properties in the draft CSS Text 4 spec that aim to help here, but implementations have not yet caught up with the more sophisticated controls there.
So in short: yes, enhancements in that area are desirable; but that's a separate topic from the capitalization factor. Here, we're at least enabling hyphenation for capitalized Afrikaans words, so that should help with your most pressing issue.
Description
•