French translation for the lazy-loading reference
#2055
Conversation
Preview URLsFlawsURL:
External URLsURL:
(this comment was updated 2021-09-22 11:37:14.318783) |
There was a problem hiding this comment.
@tristantheb thanks for the changes.
However, I don't feel comfortable with some of these changes, especially concerning the lang attribute :)
| --- | ||
| <p>Le <strong>chargement différé</strong> (en anglais <i lang="en">lazy loading</i>) est une stratégie d'identification des ressources non bloquantes (non critiques) afin de ne les charger qu'au moment où elles sont utiles. C'est une façon de raccourcir le <a href="/fr/docs/Web/Performance/Critical_rendering_path">chemin critique de rendu</a>, ce qui se traduit par une réduction du temps de chargement de la page.</p> | ||
| <p>Le <strong>chargement différé</strong> (<em>lazy loading</em> en anglais) est une stratégie d'identification des ressources non bloquantes (non critiques) afin de ne les charger qu'au moment où elles sont utiles. C'est une façon de raccourcir le <a href="/fr/docs/Web/Performance/Critical_rendering_path">chemin critique de rendu</a>, ce qui se traduit par une réduction du temps de chargement de la page.</p> |
There was a problem hiding this comment.
@tristantheb lang attributes are useful for screen reader users (allow to indicate the lang speech to use to vocalize the text). I'd not remove them, as it provides a better accessibility for these users.
Also, is not the best choice here. We don't want to emphasize this text, we want to write it in italics to visually indicate that this text is in English.
|
|
||
| <h2 id="strategies">Stratégies</h2> | ||
|
|
||
| <p>Le chargement différé peut être appliqué sur de multiples ressources et avec de multiples stratégies.</p> | ||
|
|
||
| <h3 id="general">En général</h3> | ||
|
|
||
| <p id="code_splitting"><strong>Division du code :</strong><br> | ||
| Le code JavaScript, CSS et HTML peuvent être divisés en petit morceaux. Cela permet de n'envoyer que la portion de code nécessaire à l'affichage sur l'écran de l'internaute, et donc d'améliorer les temps de chargement. Le reste sera chargé sur demande. Deux systèmes sont possibles :</p> | ||
| <p id="code_splitting"><strong>Division du code :</strong><br> |
There was a problem hiding this comment.
@tristantheb non-breaking spaces are needed here to avoid orphaned ponctuation on small screens.
|
|
||
| <ul> | ||
| <li>division par points d'entrée : séparation du code en différents points d'entrée au sein de l'application ;</li> | ||
| <li>division dynamique : séparation du code où des déclarations <a href="/fr/docs/Web/JavaScript/Reference/Statements/import"><code>import()</code></a> dynamiques sont utilisées.</li> | ||
| <li>division par points d'entrée : séparation du code en différents points d'entrée au sein de l'application ;</li> |
There was a problem hiding this comment.
Same here, no-breaking spaces are needed, please don't remove them :)
| </ul> | ||
|
|
||
| <h3 id="javascript">JavaScript</h3> | ||
|
|
||
| <p><strong>Module <code>type</code> pour les balises <code>script</code> :</strong><br> | ||
| Toute balise script utilisant <code>type="module"</code> sera traitée comme un <a href="/fr/docs/Web/JavaScript/Guide/Modules">module JavaScript</a> et son chargement sera différé par défaut.</p> | ||
| <p><strong>Module <code>type</code> pour les balises <code>script</code> :</strong><br> |
There was a problem hiding this comment.
Same here, no-breaking spaces are needed, please don't remove them :)
|
|
||
| <h3 id="css">CSS</h3> | ||
|
|
||
| <p>Par défaut, les fichiers CSS sont traités comme des ressources <a href="/fr/docs/Web/Performance/Critical_rendering_path">bloquant le rendu</a>, donc le navigateur n'affichera aucun contenu traité tant que le <a href="/fr/docs/Web/API/CSS_Object_Model">CSSOM (pour <i lang="en">CSS Object Model</i>)</a> est construit. Les fichiers CSS doivent être légers, délivrés aussi rapidement que possible, et l'utilisation des types de médias et des requêtes média est conseillé pour ne pas bloquer le rendu :</p> | ||
| <p>Par défaut, les fichiers CSS sont traités comme des ressources <a href="/fr/docs/Web/Performance/Critical_rendering_path">bloquant le rendu</a>, donc le navigateur n'affichera aucun contenu traité tant que le <a href="/fr/docs/Web/API/CSS_Object_Model">CSSOM (pour <i>CSS Object Model</i>)</a> est construit. Les fichiers CSS doivent être légers, délivrés aussi rapidement que possible, et l'utilisation des types de médias et des requêtes média est conseillé pour ne pas bloquer le rendu :</p> |
There was a problem hiding this comment.
lang attribute is needed for better accessibility.
|
|
||
| <p><strong>Polyfill</strong><br> | ||
| Pour ajouter la prise en charge de l'attribut <code>loading</code> sur les vieux navigateurs qui ne sont pas compatibles, vous pouvez utiliser le polyfill suivant : <a href="https://github.com/mfranzke/loading-attribute-polyfill" rel="noopener">loading-attribute-polyfill</a></p> | ||
| Pour ajouter la prise en charge de l'attribut <code>loading</code> sur les vieux navigateurs qui ne sont pas compatibles, vous pouvez utiliser le polyfill suivant : <a href="https://github.com/mfranzke/loading-attribute-polyfill">loading-attribute-polyfill</a></p> |
There was a problem hiding this comment.
No-breaking spaces are needed here :)
|
|
||
| <p><strong>API <i lang="en">Intersection Observer</i></strong><br> | ||
| <a href="/fr/docs/Web/API/IntersectionObserver">L'API Intersection Observers</a> permet à l'internaute de savoir si un élément suivi est entré ou est déjà dans la zone d'affichage.</p> | ||
|
|
||
| <p><strong>Gestionnaires d'évènements</strong><br> | ||
| Lorsque la compatibilité navigateur est cruciale, vous pouvez utiliser ces quelques options :</p> | ||
| Lorsque la compatibilité navigateur est cruciale, vous pouvez utiliser ces quelques options :</p> |
There was a problem hiding this comment.
Non-breaking spaces are needed here :)
|
|
||
| <ul> | ||
| <li><a href="https://github.com/w3c/IntersectionObserver">polyfill pour l'API <i lang="en">Intersection observer</i></a> ;</li> | ||
| <li><a href="https://github.com/w3c/IntersectionObserver">polyfill pour l'API Intersection observer</a></li> |
There was a problem hiding this comment.
lang attribute is better for screen reader users
| <li><a href="https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css"><i lang="en">CSS bloquant le rendu</i> (en anglais)</a></li> | ||
| <li><a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization#optimizing_loading_and_rendering"><i lang="en">Optimiser le chargement et le rendu</i> (en anglais)</a></li> | ||
| <li><a href="https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video"><i lang="en">Chargement différé des images et des vidéos</i> (en anglais)</a></li> | ||
| <li><a href="https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css">CSS bloquant le rendu (en anglais)</a></li> |
There was a problem hiding this comment.
please don't remove those lang attributes :)
|
Simply for a question of compatibility with Markdown. Markdown doesn't support things like language attributes, classes, and many other elements that we don't convert. |
|
If I may interject:
With all that in mind: I think we shouldn't discourage good/"deep" semantics (like having the lang attribute for such cases) but we shouldn't be too strict for other contributors who are not aware of that when evolving in a markdown world In other words (to me): having HTML lang attributes is fine, having italics text in Markdown for other languages is better that no typographic styling. @wbamberg : have you had any similar request/feedback on Markdown format for typography/localization? (in French, we use italics and <i lang="locale-code"> to indicate words in another language, e.g. |
No, we haven't. Of course Markdown is much more limited here. At the moment the only way to support this would be to use HTML. For what it's worth I have pretty intimate knowledge of MDN's en-US markup over thousands of pages, and I can say that in general we don't use semantic HTML (because of 15 years of being a Wiki with no real policies or tooling for ensuring it), so in practice, in en-US anyway, we are not losing much. |
|
@tristantheb, @audrasjb I've "merged" your reviews and "applied" mine. My opinion is that for inline anglicisms (e.g. "lazy loading" here) I'm going to merge this as the quality of this content is already great enough, let's not bikeshed too much 👼 |
|
Sounds great to me, thanks @SphinxKnight 👍 |
This PR aims to add a French translation for the
lazy-loadingreference on MDN.