French spaces

Hi there,

Verdy p insists to put narrow non-break spaces (U+202F) everywhere instead of normal non-breaking spaces (U+00A0) before or after punctuation symbols in French translations. Narrow non-break spaces are not compatible with all browsers, notably Safari on macOS and iOS, which is a big part of the readership on Wikipedia and elsewhere. Instead of a space, there's no space at all.

In French typography, both are correct but the normal non-breaking spaces have the advantage of being compatible everywhere and being coherent with the choice made by MediaWiki, the French Wikipedia community and the other French-speaking projects.

He also use translations that are rarely used [1].

Can we do something?

Thanks.

Hello, I support the fact that we need to be accessible for all and Verdy_p doesn't help with that. He don’t want to understand this point.

Not compatible ??? They are standard since so many years. I've never seen any browser not supporting it since extremely long. May be your iPhone is very old. But your claim that iOS is a very large is false. It is a small minority (and even much smaller if you consider very old versions of iPhones with outdated fonts).

NBSP are incorrect in standard French, they were used 20 years ago but NNBSP was adopted after many requests from French publishers. They are even required for Mongolian (OK this is a minor language) and other Asian scripts where they are even DISTINCT from NBSP.

May be they are not used in wikitext of articles, because this is simpler, but they are used since very long in translate wiki for the UI.

Your claim of "incomplatiblity" is not justified by any proof. NNBSP is in Unicode since version 3.0. They are also standard in French translations for CLDR.

• Non-breaking_space#Width_variation

The source code of ICU for iOS perfectly handles NNBSP:

• https://github.com/zhm/icu-ios/blob/master/icu/source/common/uchar.c

Lot of iOS/MacOS programmers are told about what to do: NNBSP support *is* highly recommanded and its support is integrated in many libraries

ADE 2.0+ (more precisely RMDSK 9.2 and beyond) display correctly the nnbsp whatever may be the font. This applies to a lot of ebook-readers like Kobo. InDesign does the same.

No need of any font mapping for whitespaces. The Unicode properties are honored by compliant renderers (indepenantly of the supprot for the Mongolian script which is still problematic and still in discussion in 2019, these talks do not apply to the encoding of any other script)

Unicode states already (and agrees) that:

• NNBSP is non-breaking
• it has a fixed width in all contexts
• it is not expandable during justification (NBSP is expanded and is NOT usable as a group separator or punctuation separator).
• it MUST be narrower than a regular space or digit (FIGURE SPACE is like NNBSP but not suitable as a group separator, only as a digit replacement in tabular data when no zero should be visible). For monospaced environments, rendering it as a full space (like the FIGURE SPACE) is NOT acceptable.
• it should behave like the FULL STOP or COMMA in the middle of numbers or in sequences of punctuation signs.
• it is a significant character (not a format control like the Mongolian MVS, or ZWNBSP, or ZWSP, or WORD SEPARATOR).
• it is not necessarily ignorable in all locales for collations (e.g. when it is used to differentiate numeric codes)

Unicode really instructs auhtors to NEVER use NBPS for group separators in numbers, but use NNBSP instead. Since the origin, NNBPS was introduced to be script-agnostic (the claims made by some that NNBSP was only for Mongolian was wrong, this created a temporary bug in Apple's code, reclassifgying it incorrectly as neing for Mongolian, Apple fixed that very fast as it was their error). Initially NNBSP was flawless, even in iOS ! all other apps (including Discord on iOS) have fixed that (or they provide a workaround in their app-builtin renderer for the few remaining iOS phone versions affected by this bug committed incorrectly by a Apple programmer). These smae vertsion of iOS (only with their builtin bogous Safari browser and no other browser installed) are not even accessible (so the claim of "'accessibility" being broken only by NNBSP is false; these versions of iOS are not accessible at all for MANY other reasons). All this does not concern MacOSX and all newer products that have fixed this bug (and now support Mongolian much better).

The affected software versions are NO longer maintained by Apple, and this was a propriary bug on a very small set of specific implementations that is out of market since long. and Apple has made many tricks in iOS so that even these models are no logner usable with all the needed security and accessiblity features that are needed today. These old versions were even incompatible with Mongolian (and never supported that script correctly, allowing only very bogous and ugly rendering of Mongolain only in its horizontal form, but incorrectly rotating some glyphs and not rendering the basic required conjuncts correctly).

You also made a false claim that Discord is only for iPhones. I use Discord (on Windows, sometimes Linux, also on Android) but I've never used any iPhone. All modern browsers support ALL spaces (without even needing any font mapping, as they can be synthetized, given they have no glyph, and just suggested metrics that can be computed, and standard breaking properties). NO browser must display any "tofu" for characters that have a Whitespace property. This is effective since long.Unicode provides the fallback mechanism and explicitly says that the default fallback must be either nothing/zero-width (for languages like English or Mongolian, or in every monospaced rendering, including Chinese, Japanese, Korean) or NBSP (for French for example) if the browser cannot synthetize the metrics for proportional rendering.

Even in XP, there's no problem. May be there are very old version of IE, but they are so old that they cannot even support the minimum Javascript that is needed for Mediawiki or even Discord itself! Their users are instructed to install and use another compliant modern and supported browser (like Firefox, Chrome, Chromium, Opera...) of they don't comply to the standard and don't even have the minimum Unicode 4.0 support (NNBSP was pubnlied long before in Unicode 3.0, I don't know any browser that just supports Unicode 3.0; not even in plain-text console browsers where NNBSP should be invisible with monospaced fonts, and this is not a bug, while NBSP is very ugly in such context where NO extra spacing is needed with punctuations or even as group separators in numbers, where these group separators for accessibility do not math the fact that monospaced text is already not designed to be accessible or even compatible with all scripts).

Note that even if NNBSP was initially introduced for Mongolian, it was later replaced in the Mongolian script by MVS (Mongolian vowel suffix separator). It was not deprecated at all for other languages (FVS1, MVS, ZWJ are now recommended for Mongolian, which is a vertically written script, whereas NNBSP, ZWNJ, FVS3, FVS2 are deprecated only in Mongolian; the NNBSP remains the non-breaking equivalent of THINSP for all other scripts)

Hi.

TLDR;

Thin space is not visible on my ipad (iOS, Safari), so I reverted your edit. Thin spaces are cool (we often use them in press and printing), but as long they don't work on all common OS/web browsers, don't use them.

Regards.

tl;dr as well.

"May be your iPhone is very old."
Nope it's not.

"Your claim of "incomplatiblity" is not justified by any proof."
Here's a screenshot from Safari and another screenshots from Firefox, Chrome and Opera. All browsers on iOS must use the same web rendering engine as Safari anyway to be accepted in the App Store.

"You also made a false claim that Discord is only for iPhones."
I didn't say that, I said that Discord is often used on mobile and translations should be fully compatible on all current mobile operating systems, including iOS (all translations on this website should be). Btw I'm using Discord on my Windows PC right now.

FYI, I just tested on Safari 12.1 on macOS 10.14.4 (Mojave) and the thin space is invisible as well (screenshot).

Edit: Like Jules78120 said above, thin spaces are good for books and publishing but a bit overkill for interface messages and strings of text sent by a bot.

There is 2 problems here:

• the typography, thin space is in theory the good solution but it doesn't work
• the attitude of Verdy_p, unable of efficient and sane discussion

The first is technical, we can look at the facts and act accordingly.

For the second, I have no idea and I'm sorry but I prefer to let someone else do something about it.

Not compatible ? Only uninformed users. See:

https://www.mobileread.com/forums/showthread.php?s=d2dc1cdf14e21e2f251a838f4e7dcfc4&t=189487

Many places in Apple forums and documentation tell that NNBSP *is* supported and even strongly recommended (and no need to embed any font in your ePUB; as well there are other ePUB readers, and were's not even translating here any interfzace of old proprietary ePUB reader for Apple OSes). Apple has fixed its readers and published the details for authors.

So this is a problem of 'lazy' users refusing to read the recommendations that are largely adopted everywhere else (and remember that users of these old Apple devices are a very small community, ready to pay to lot to Apple, but refusing to upgrade their device, OSes or use a better software than the builtin default?) Accessibility is not a concern. All standards agree that NNBSP is and must be supported and the initial bug of Apple has been acknowledged by Apple, and tyhe work around has been made in all serious apps (including in Discord for iOS).

And if you feel offended by the term "lazy", this is a fact: I give many justifications and there are tons of links on the web and support not just from me. But if you don't want to read them, you don't need to talk here and just say "TLDR" (which is NOT a valid argument).

Ad hominem attacks are not arguments either.

"So this is a problem of [...] users refusing to read the recommendations that are largely adopted everywhere else"
That's the pot calling the kettle black, you refused to acknowledge that the Imprimerie nationale and the Office québécois de la langue française, two authorities when it comes to French typography, don't recommend thin spaces between French quotes.

And here this is about ":" and about a user not seeing the space which is present and visible in its own screenshot. And this is for the UI on specific smartphones or small tablets. No user will have to input this, as it is only displayed and convenient for them. And you have a very strange interpretation of "ad hominem". I gave many sources, and all standard bodies and even Apple have approved it, reaffirming that NNBSP was for this purpose (decommitting it only for the Mongolian script for which it was initially unified in the first encoding in Unicode 3.0). Unicode, CLDR, Apple, Microsoft all recognize that this is strongly supported (and was demanded by many publishers, including in France; do you remember that I have worked for many years for ALL publishers in France (for national and regional newspapers, magazines, books, guides, diaries... as well as professional/specialized press, and public papers) and also in Belgium, Luxembourg, Switerland, Italy, Spain, Canada, North Africa, Lebanon, and the Middle East: they all demanded that support in the composition softwares we were selling them. At that time, HTML was not used (it was insufficient and the NNBSP was not even existing in Unicode, but the character already existed in SGML and in their databases of encoded texts (they were represented using defined character entities). That "fine insécable" was (and has remained) required as the group separators in numbers and along with all punctuations needing extra spacing attached to them. Using NBSP was unacceptable, and in Unicode the NBSP is expansible like regular spaces, making it unsuitable (and totally incompatible even as group separators and in all financial applications as it would become confusable with figure spaces (which are also unexpansible) The two authorities you speak about made old recommandations for HTML but this was before Unicode 3.0. They were both asking for a proper support of NNBSP since years to the W3C and to ISO and Unicode. This was affirmed by them in the ISO standards and working groups for SGML (which was then their reference framework; their adoption of HTML came much later and now Imprimerie Nationale also uses HTML publications with NNBSP: the old recommendation for old versions of HTML3/4 and based on legacy 8-bit charsets is no longer applicable).

"And here this is about ":" and about a user not seeing the space which is present and visible in its own screenshot."
Regarding :, here's another comparison, with the thin space at the top and no space at the bottom, tell me where do you see a difference.

"I have worked for many years for ALL publishers in France (for national and regional newspapers, magazines, books, guides, diaries... as well as professional/specialized press, and public papers) and also in Belgium, Luxembourg, Switerland, Italy, Spain, Canada, North Africa, Lebanon, and the Middle East: [...]"
Argumentum ad verecundiam, not an argument either.

Arrête de sortir ton latin. Visiblement quels que soient les éléments pourtant facilement vérifiables et les sources indiquées, tu n'en tiens pas compte et tu résumes avec ton avis simpliste qui ne s'appuie sur pas grand chose, sauf des préconceptions anciennes que tu réinterprètes et veux étendre comme tu veux. Je me suis appuyé sur des normes, des documents de constructeurs, d'éditeurs, sur mon expérience pro (tant pis si tu ne veux pas en tenir compte ou ne pas me croire, mais si tu avais travaillé dans le métier de l'édition, ces fines qui existent depuis des siècles (avant même la bureautique puis l'informatique qui au départ avait trop simplifié les choses pendant juste quelques décennies sans remettre en cause pourtant les usages des éditeurs, avant elle aussi de reprendre les règles typographiques justement avec la forte demande des éditeurs et imprimeurs internationaux qui naturellement ont travaillé avec les éditeurs de logiciels pour faire intégrer ce qui était resté leur coeur de métier.) Mais ce n'est pas nouveau, tes compétences "informatiques" toutes fraiches n'ont pas cette expérience et tu restes cantonné à des approximations simplistes parce que c'est comme ça que tu as toujours fait, et surtout parce que tu ne veux pas en changer. Et pourtant l'informatique aussi évolue. La typographie n'est plus un luxe facultatif (et là il y a une combinaison de facteurs: le codage du texte, les évolutions des technologies de polices et de celles des moteurs de rendu, et c'est bien cette combionaison qui entre en compte dans tes exemples de capture finale, où il n'y a strictement aucun problème. Mais tu veux créer des problèmes là où il n'y en a aucun, et ne veux pas reconnaiotre que NBSP n'est PAS du tout fait pour ça, qu'il n'a pas les bonnes propriétés, et Unicode lui-même le précise. Les usages de NNBSP sont bien documentés et ont de très nombreux soutiens officiels et commerciaux (mais quels qu'en soit le nombre de toute façon tu ne veux pas en tenir compte), et aussi de nombreux particuliers tout aussi interessés. Ce n'est pas une "lubie", une invention de ma part. Et pas besoin sortir du latin (mal placé, car visiblement tu n'as pas lu du tout ni compris l'article en anglais lié : tu n'as strictement aucune "autorité" qui défend ta position ou tu les as elles aussi très mal comprises). Maintenant que ce soit des arguments d'une autorité, des arguments basés sur l'usage , et d'où que ça vienne en fait, tu continueras à faire cavalier seul, et même à nier des évidences que tu as toi même présentées: tu nies même ta propre autorité, bref tu t'es contredit toi-même. Bref tu ne donnes que ton opinion personnelle. D'autres ont leurs opinions et ils sont nettement plus nombreux, le choix est entériné, et je suis très loin d'être seul comme tu peux l'être ici en continuant à nier l'évidence.

Oh wow, new personal attacks, did you run out of arguments?

I'm sorry but your sources are completely off-topic and your walls of text where you state your personal opinions as facts are not backed with any proof.

You fail to see the reality where your thin spaces are not compatible everywhere and that we must use non-breaking spaces for the time being. Translations must be accessible to everyone, no matter what their browser/device is.

EDIT: If you want to reply, please use the "reply" function, don’t edit other people’s messages.

Your screenshot is using a font whose glyph for ":" is already enlarged, and Unicode also sayss that in such case it is perfectly acceptable for NNBSP to become invisible.

This is a same rationale with the ideographic rendering with fullwidth punctuation: they dont need extra spacing at all.

NNBSP is in the Times font recommanded for ePUB (and supported as one of the 7 default fonts for the Apple's iBok reader not needing any font embedding). It is used by default in serious publications.

If you use the default font for the web which uses enlarged characters for accessibility (or you tune Windows web browsers with Verdana instead of the default Arial or Segoe UI), NNBSP can legally be mapped or tuned by the browser to become invisible (this is legit, it remains fixed-width, non expandable by justification, and non-breaking as expected). NBSP breaks the text and is too large (it can be a valid fallback only for FIGURE SPACE, as long as it is not expanded in justification like regular SPACE).

NBSP does not have the needed properties. All standards agree : CLDR, IBM, Apple, Unicode, Mozilla, Microsoft, LibreOffice, Monotype, French typographic sources and publishers (including commercial ones, like Hachette, or public ones like the JORF), and even US publishers for English: they all use NNBSP for French punctuations and group separators.

NBSP was a temprary workaround used at the early stage of Unicode before version 3.0. When Unicode 3.0 was published, it was correctly supported as well by Apple, until they started creatging havoc and proposed a way to fix it. Renbdering NNBP as an invisible space is valid with the default proportional "sans-serif" fonts of MacOS/iOS whose glyph metrics already embed larger gaps between glyphs. Helvetica (licenced by Apple from Adobe) embeds the NNBSP character, but that old font is not recommended at all for reading the web on a screen (even with HiDPI screens) as it is not accessible and was only tuned for monochromatic laser printing at 150-300 dpi. Helvetica is deprecated but remains a default for old MacOS devices (not MacOSX that have better fonts with more accessible metrics).

Maybe your technical explanations are true (but not sure: my iPad, "given" by my employer, is not old and is up-to-date…), but what I can say is that on my iOS device, on Safari, the thin space is not displayed. Please stop arguing about the theory and take into consideration the reality…

Regards.

And please stop to impose your thin space, as there is no consensus for it and while thin spaces are not displayed on iOS devices.

I'm definitely not alone to defend NNBSP in French. There are lot os sources, and your problem for having it invisible on your specific device does not cauyse any harm even to you.

Your display is not broken/unreadable even if your device uses ugly fonts with ugly/overlarge punctuations with extra padding (in fact it jsut happens that your font maps this NNBSP to zero-width, which is coherent with the design of its ugly punctuations)

Change your font preferences in your browser (instead of the legacy fonts), you'll see the difference if you want. But that's not needed at all for the UI that you'll want to make discrete and compact, to leave more space for the content. It would be a problem if you saw ugly boxes for unmapped glyphs, but your browser does not even do that!

Why do you want to force a visible space here ? When your device uses a font with builtin enlarged punctuations ? With such a font with ugly punctuations like ":", NNBSP being rendered invisible is NOT a problem. This is legit. But NBSP is definitely bad (even worse with your font, it would be definitely too large). You msut know that NNBSP is used in so many places. Apple has made statements about how to cope with that. If you use the default builting sans-serif fonts even in browsers, haing it invisible is correct; if you render the page with a serif font, the default builtin font "Times" correctly renders that NNBSP. In both cases, it is supported.

If you use other fonts than these defaults, you will see the difference if you insist,, but such use is only for page design or when writing text, and even in the Wikitext editor you can see it with the monospaced font. But for the UI rendering it's still best to have it rendered as zero-width near punctuations (not at all an accessibility problem for this font). In fact it better fits the limited screen size on lowend iPhones.

And on the web, nothing forbids you to change the fonts (there are preferences for that in Apple's web browser). Did you read the links above ? Apps and other browsers can still work around this when they need, even if fonts don't map this character and EVEN if they are forced by Apple to use the Safari's internal rendering engine.

You don't care, but you're part of a very small minority and the large majority want to use the standards and official recommendations (that don't even break your device and makes the content inacessible to you if you don't want to change the device settings).

A space not displayed is not a problem? Hum… Yes, it is a problem. In French typography, a space (thin is better, but not mandatory) is needed before punctuations like ":" or ";". So a space… must be displayed. Simple.

(most) People use their devices as they are, we don't have to expect they will change their fonts or use workarounds. We have to make sure spaces are displayed on all devices. Stop saying that only old devices don't display thin spaces: mine is not old (about 2 years) and is up-to-date.

You don't bring any proof that thin spaces are a standard (we don't use them at all on Wikipedia for example) and you ignore the fact that, even if it was a standard, it is not yet followed by all browsers/OS.

False. It must be added ONLY when punctuations in the fonts you use do not have enlarged paddings. It is not needed at all for monospaced fonts or if punctuations have been tuned to embed extra padding, as what is visible in the screenshots you provided above, which ios perfectly fine and shows NO bug at all.

And this is still not our problem: in French, spaces must be displayed before ";", ":", "!", etc., period. If iOS or other platforms don't display thin spaces, go talk to them, but don't use thin spaces as long as the result is that spaces are no displayed for readers. Please.

But the space IS present, I have never "removed" it. And it IS displayed (even in your image, it is visible with your iOS renderer, and accurately it is thin as expected).

So you've not demonstrated any actual problem. The French typography is respected even on your iOS device ! It is thin but clearly visible on the ouput (you can measure it easily,the gap on sides of the colon or question mark is about twice larger than the average gap between 2 letters).

You use bad faith argument by pretending you don't see it, when your screenshots clearly demonstrate the opposite.

Is this a joke?

You're the one using bad faith arguments by pretending seeing an imaginary space, when my screenshots clearly demonstrate the opposite.

Here's a comparison with the thin space (top) and without any space (bottom), can you now tell me where do you see a difference? (protip: there's none)

Actually, the majority (the general public, the readers) don't know what a non-breaking or narrow non-breaking space is, they just want a space before : ; ! ? » and after « like it's supposed to be in French, whatever their device or browser is. Period.

And they see that even in iOS (the screenshots show above demonstrate that the punctuations are not "too near" from the characters before or after them, there's alreadyu the thin space inside each punctuation sign. these are legacy fonts anyway from Apple, and if you want finer typography, Apple recommands application authors to use better fonts, or users to setup their browser.

NBSP is not suitable as it is really too large for normal reading (remember they won't have to edit these UI texts, they just want to read it and without wasting screen space. NBSP is wrong in all French texts for ALL users; it was only a workaround before the encoding in Unicode 3.0. And NNBSP is kept for all scripts, except for the Mongolian vertical script where it is deprecated and replaced by MVS, NNBSP remaining valid however for punctuations even in Mongolian; and Mongolian does not use spaces as group separators for numbers).

We talk here about French only, and your screenshot does not demonstrate any problem: the extra spacing is present and visible along with normal French punctuations (but the same punctuations are ugly in non-standard uses of punctuations like sequences "::" or ":-;". And there's no problem at all for terminal monospaced fonts where these spaces are not needed and can safely become zero-width (and still remain fixed width, non-justifiable, non-breaking and narrower than regular spaces or figure spaces in all cases).

No, there are no space at all.

Here's another screenshot.

Measure the gap between the two glyphs between the letter and the following "?", compare it to the gap with the previous letter; it is LARGER (yes, there's extra padding inside the "?" in that font, so that NNBSP does not need to be visible with that font).

This is Apple's design of that font. No bug ! Adding a NBSP will just make the resultint text more ugly and not compliant to common typographic practices. And it will behave very bad for UI design (remember we are translating an UI), or in Monospaced environment (where NNBSP is also zero-width), e.g. on terminals on old typewriters (where no extra spacing was needed at all).

In other devices (Linux, Windows...) NNBSP is what is needed to get the same spacing, because gaps are NOT part of the OpenType design of standard punctuations.

(I bet that this Apple font is ugly for Swedish, where a ":" can appear in the middle of a word to attach suffixes, and that ":" is not cutting the sentence in two parts but may be Apple provided a Swedish tuning in that font to conditionally cancel that extra gap between two letters). Apple has very specific proprietary rendering engine that an do that with complex AAT rules in its proprietary fonts, instead of standard OpenType fonts).

Anyway, AAT is being deprecated by Apple in favor of OpenType, but legacy fonts for MacOS and iOS will keep their AAT tables for legacy compatiblity reasons. The Apple's renderer in its browser allow applications to drop the AAT rules and use only OpenType/TrueType rules (and in that case NNBSP will be distinctly displayed, and no gap will be added into OpenType/TrueType metrics, NNBSP will be non-zero width). These Apple tricks in its default legacy fonts are not used in Times (recommanded for text publishing, and also used normally by default on the web; Apple also offers other fonts now for web content and applications UI, where NNBSP is mapped or handled directly by the renderer without needing any extra mapping).

Did you try changing your default font instead of the proprietary legacy ones (that have also poor I18n support with limited coverage for Latin) ?

About the thing of uncommon translations, it is completely besides the point of this thread but you people should avoid just indiscriminately adopting English terms when you could use plainer terms, and in this case, “en source ouverte” is a direct, easy-to-understand equivalent of “open source”, understandable for people beyond geeks. Other Romance languages translate the term as well: de código abierto (es), de código aberto (pt), de codi obert (ca), de códigu abiertu (ast), cu sursă deschisă (ro)… Anglicisms can be necessary and I don’t censor them, but in this case it is gratuitous and avoidable.

C'est aussi mon point de vue. Je ne vois pas l'intérêt de l'anglicisme ici, nombre de geeks se foutent pas mal de leur langue tant qu'il parlent leur jargon technique et ne cherchent justement pas à impliquer les autres et se fichent pas mal de rendre leurs projets accessibles et compréhensibles par plus de monde.

Rien n'empêche de toute façon ensuite aux techniciens bilingues et les mieux formés d'utiliser le terme anglophone quand ils vont sur des espaces anglophones, mais puisqu'ils sont mieux formés je ne voit pas ce qu'il leur en coûte d'utiliser une terminologie française correcte dans une traduction française qui justement ne leur est pas destinée directement, mais qu'ils comprennent très bien.

Il n'y a rien de plus rebutant pour un novice de se confronter à autant d'anglicismes non nécessaires dans les projets collaboratifs supposés justement "ouverts", mais qui se replient justement à des petites communautés installées de techniciens qui se croient irremplaçables et indispensables et les seuls à "savoir" (alors qu'ils méprisent autant le savoir de langue humaine, au seul profit du jargon informatique où ils sont les "dieux"). Nos projets devraient être ouverts aux novices, et c'est encore plus important pour ici un terme qui veut dire ouvert à tout le monde, et dans un contexte aussi promoteur de l'éducation que le veut clairement Wikimedia. "Tout le monde" ne veut surtout pas dire "Tout le monde anglophone" (sachant aussi que le jargon informatique déforme et abuse aussi beaucoup la langue anglaise avec trop de raccourcis, et encore plus d'expressions ambiguës qui ensuite viennent "plomber" même le code écrit).

Faire comprendre un terme technique permet aussi d'éviter les mauvaises interprétations et les mauvais usages, même si ensuite l'association vers un terme anglophone correspondant est vite apprise. Tout est une question de respect et d'ouverture aux autres.

If we really want to translate this common anglicism, the correct French translation would be "code source ouvert", not "source ouverte", which is a bad calque from English.

In general, MediaWiki tries to follow Unicode. We could debate forever on what to do with devices which have poor support for i18n. This is a matter of style, not semantics, so we ought to be consistent (ideally) but at the same there is no urgency justifying a mass edit war.

I use DjVu Serif and an edit like special:diff/9131394 adds a space for me before the colon, where previously there was none. It's clear that the translations did not follow a consistent rule.

I urge the French translators to have a discussion on portal talk:fr (in French is better), involving all those who used or did not use the various kinds of spaces in the past. It's important to find a consensus on 1) what space would be preferrable in an ideal world, 2) what space is recommended right now (this should be written on portal:fr so future translators can learn about it), 3) whether it's ok to perform mass changes to impose the recommended style.

I suspect the solution will come from software, just like we have a special exception in the MediaWiki parser to deal with French spaces. After you have a consensus on what an ideal world would look like, please post a feature request in MediaWiki-Internationalisation, so the devs can see whether spaces can be added/standardised on the display side (some even use CSS for this purpose, I believe), possibly based on the device as well.