For now the workaround is to place the text content of the link within the brackets and not expect that it will expand outside on touching letters (this only works on ASCII letters, not on non-ASCII letters that are UTF-8 encoded).

There's some regexp that controls how many characters to add to the link, but it just accepts ASCII digits [0-9], ASCII letters [A-Za-z] and a few "continuing punctuations" such as [_].

To cover non-ASCII only contents (including for English!) we should still not include all non-ASCII characters but only characters that are in some simple class. The problem is that regexps to match characters with UTF-8 can be fairly complex to write (but it's still possible to write it) and it is not a closed subset of the Unicode repertoire (because it is extensible: Unicode adds regularly letters, digits and some other useful symbols which could or could not be included such as emojis, we should however exclude whitespaces, but include all combining characters, plus a few controls such as CGJ/ZWJ/ZWNJ/WJ joiners needed in the standard orthography of some languages)
At each revision of Unicode, we would need to regenerate this matching regexp.

Unicode provides data for character subsets useful for identifiers (idstart, idcontinue) that we could use for matching these textual extensions of wikilinks (after the two closing brackets). It is easily recompilable into a UTF-8 matching regexp. Such regexp is already used internally by Javascript and HTML5 for recognizing their valid identifiers

However this could cause problems with languages that usually don't use whitespaces to separate words in their scripts (notably Chinese, Japanese, or Korean with their sinographic scripts, and a few other Asian scripts such as Thai): we should not extend links to all touching sinograms which would include a full sentence (not fully relevant: it would obscure the page with overlong links everywhere).

We could also break the link if there's a strong script change (e.g. any switch from CJK sinograms to Latin, including "wide" Latin characters used in CJK, or the reverse), but not for characters that are using weak scripts (e.g. ASCII digits, shared across many scripts): using regexps in this case would be more complex as we would need to use distinct regexp depending on the last strong script of the last character of the link text within the bracket)

So I think that writing "[[Link]]s" (or "[[Target|Link]]s") instead of  "[[Target|Links]]" (or "[[Target|Links]]") is just an ***old (deprecated) trick*** of MediaWiki used by (lazy) wiki redactors, we cannot recommand using it:

The longer form will be preferred (where all characters to include in the link should be within the brackets), even if there's still some support for (ASCII-only) text link extensions (after closing brackets) to /[0-9A-Z_a-z]+/.

And I see no reason to handle this case to only to cover all extensions of the Basic Latin script (or even just for Hungarian), or even with other alphabetic scripts (Cyrillic, Greek) or abjads (Hebrew, Arabic) and some Indic abugidas (but not all of them use whitespace for word separation!), or simple syllabaries (such as Ethiopic, or Canadian Syllabics: should we include Hangul, Bopomofo and Katakana/Hiragana when they are mixed with signograms and now necessarily whitespace separated?).