Dislike German Klammerplural ;-)

Help / Discuss
1

The Klammerplural (bracketed pluralization) is a German writing convention used to indicate both singular and plural forms of a word within the same sentence. No surprise—we do quirky things in German language! :wink:

Example:

…die hier beschriebene(n) Anwendung(en)

This Klammerplural is unfortunately displayed as:

…die hier beschriebene👎 Anwendung(en)

While I find this “dislike” interpretation quite amusing, is there any way to prevent the misinterpretation of (n) as :-1:?

1 Like
2

This transformation comes from xwiki rendering transformation.

To be honest, IMO we should spend a bit of time to rework this emoticon system but it’s not been a priority (and modifying rendering can easily break backward compatibility, from my experience it’s more dangerous on average than things in xwiki-platform) so it’s still waiting.

Since XWiki 8.4.5+/9.3RC1+. If you wish to remove a default mapping, simply redefine the emoticon with a blank value. For example to prevent (n) from displaying you’d add:

rendering.transformation.icon.mappings = (n) =

Have a good end of the day,
Lucas C.

3

If it’s a common thing in German, maybe we can have this icon remapped somewhere in a german-specific translation? I’m not sure how we’d make it properly though.

Maybe it needs some improvement on our internationalization system such as XWIKI-585: Translatable objects to be cleanly implemented in XWiki Standard.

4

Well, to add my two cents, I dislike how my doubts near sentences (expressed using the characters “(?)”) get rendered with the question mark icon, but that’s not really an issue for me :slight_smile:

1 Like
5

In the same way, if you think it’s better for all users of your instance, you can also disable it :slight_smile:

1 Like
6

Hi there, the very same issue exists in Czech for example: test(y) results in “test :+1:”.

Also note that another solution is to simply use the XWiki’s verbatim notation: test{{{(y)}}} results in “test(y)”. So I think it would be useful to have this verbatim option among the out-of-the-box styles available in the WYSIWYG editor’s “Styles” combobox for regular XWiki users (need to investigate Adding custom inline styles to WYSIWYG editor otherwise…).

2 Likes
7

That works quite nice. Thanks.

8

But not for the pretty name of a class property…

In this case, Test(y) results in “TEST”. I believe the reason is the uppercase formatting in the AWM sheets and, of course, the verbatim notation doesn’t work here.

9

Another way to implement a local workaround for the “(n)” rendering issue is by adding a local XWiki.StyleSheetExtension with the following CSS:

/* hide the injected icon */
#xwikicontent img[alt="thumb_down"] {
  display: none !important;
}
/* de-arm the invisible button */
#xwikicontent img[alt="thumb_down"] + button.lightbox-toggle.sr-only {
  all: unset;
  display: inline !important;
  font: inherit;
  color: inherit;
  margin-left: 0.1em;
  pointer-events: none;
  cursor: default !important;
}
/* re-display the original (n) visually */
#xwikicontent img[alt="thumb_down"] + button.lightbox-toggle.sr-only::before {
  content: "(n)";
}
/* hide the icon for (n)-button */
#xwikicontent img[alt="thumb_down"] + button.lightbox-toggle.sr-only .fa.fa-ellipsis-v {
  display: none !important;
}

This workaround ensures that the (n) appears visually correct while avoiding unwanted interaction or styling side effects elsewhere in the UI. Since it’s scoped to #xwikicontent, it won’t affect toolbars, editors, or menus.

This is especially useful when the verbatim notation is too technical for users and if the fix has no sideefects inside #xwikicontent.

1 Like
10

The simplest solution if you don’t rely on things like (/) or (x) being resolved to icons is to just deactivate the icon transformation, for example by setting rendering.transformations = macro in xwiki.properties. That will globally deactivate these replacements.