Update localization files (2023-08-04T01:47:54.021Z)

de/markdown/docs/develop/userstyles/best-practices.md

@@ -0,0 +1,68 @@
+---
+title: Empfohlene Vorgehensweisen
+description: Follow these best practices when writing or reviewing userstyles.
+---
+
+Follow these best practices when writing or reviewing userstyles.
+
+
+<!-- TODO: ## Addon dark mode support -->
+<!-- Examples on referencing CSS variables from editor-dark-mode, dark-www and scratchr2 -->
+
+
+## Internationalization
+
+### Consider languages with longer words
+
+Remember that im some languages, UI elements such as buttons may be narrower or wider.
+
+<!-- TODO: ### Supporting right-to-left languages (RTL) -->
+
+
+## Styling existing Scratch UI
+
+
+### Avoid targeting hashed class names
+
+The Scratch project editor usually contains class names that follow the `class_name_{hash}` format. For example, `green-flag_green-flag_1kiAo`.
+
+As the hashes might change in the future and may differ between Scratch forks, you should avoid using them in userstyles.
+
+{{< admonition error >}}
+```css
+/* Don't do this: */
+.green-flag_green-flag_1kiAo {
+  visibility: hidden;
+}
+```
+{{< /admonition >}}
+
+{{< admonition success >}}
+```css
+/* Do this instead: */
+[class*="green-flag_green-flag_"] {
+  visibility: hidden;
+}
+```
+{{< /admonition >}}
+
+### Avoid `!important` unless absolutely necessary
+
+If possible, use [CSS specificity](https://web.dev/learn/css/specificity/) features to make your selectors more specific, instead of using `!important`.
+<!-- This could be more detailed -->
+
+
+## Styling addon UI elements
+
+
+### Begin addon-defined class names with `sa-`
+
+{{< admonition info >}}
+We always use `kebab-case` when defining our own class names.
+{{< /admonition >}}
+
+We recommend that addon-defined class names begin with `sa-` to avoid potential name collisions with Scratch or other extensions.
+
+It is also recommended to include the addon ID (or part of it) in the class name.
+
+<!-- TODO: ### explain usage of z-index in the Scratch editor and related concepts -->

fr/markdown/docs/develop/userstyles/_index.md

@@ -0,0 +1,108 @@
+---
+title: Styles utilisateur
+description: Userstyles are CSS rules that affect Scratch pages. They can apply styles to existing Scratch UI, as well as to elements that were added to the page by addons.
+---
+
+Userstyles are CSS rules that affect Scratch pages. They can apply styles to existing Scratch UI, as well as to elements that were added to the page by addons.
+
+
+## Declaring userstyles in the addon manifest
+
+{{< admonition warning >}}
+**Certaines modifications nécessitent un rechargement d'extension** à partir de `chrome://extensions` pour prendre effet, comme la mise à jour du fichier manifeste de l'addon.
+
+It's not necessary to reload the extension when changing the source of an already existing userstyle CSS file. In those cases, reloading the page is enough.
+{{< /admonition >}}
+
+Userstyles are declared inside a "userstyles" array, similarly to userscripts.
+
+Chaque élément du tableau doit avoir les propriétés suivantes :
+- `"url"`: the relative URL to a CSS file.
+- `"matches"`: the list of Scratch pages where the userstyle will be applied. See [matches](/docs/reference/addon-manifest/#matches) for more information.
+- `if`: a list of conditions that may toggle whether the userstyle is currently applied or not. See [userstyle.if](https://scratchaddons.com/docs/reference/addon-manifest/#if) for more information.
+
+Example :
+```json
+{
+  "name": "Scratch Messaging",
+  "description": "Provides easy reading and replying to your Scratch messages.",
+  "userstyles": [
+    {
+      "url": "styles.css",
+      "matches": ["projects", "https://scratch.mit.edu/", "profiles"]
+    },
+    {
+      "url": "resize.css",
+      "matches": ["projects"],
+      "if": {
+        "settings": {
+          "resize": true
+        }
+      }
+    },
+  ],
+  "settings": [
+    {
+      "name": "Resize messages",
+      "id": "resize",
+      "type": "boolean",
+      "default": false
+    }
+  ],
+  "tags": ["community"],
+  "enabledByDefault": false
+}
+```
+
+
+## Dynamically toggling userstyles after page load
+
+It is usually unnecessary to use a JavaScript userscript to dynamically toggle whether a userstyle is active on the page in response to the user changing settings.
+
+- Including `dynamicEnable: true` in the addon manifest will allow the extension to dynamically inject userstyles if the addon has been enabled (for the first time) after loading the page.
+- Including `dynamicDisable: true` in the addon manifest will allow the extension to dynamically remove or reinject userstyles if the addon has been toggled, without requiring a page reload.
+- Including `updateUserstylesOnSettingsChange: true` in the addon manifest will re-evaluate "if" conditions that depend on user settings without requiring a page reload. The extension will remove or inject userstyles accordingly.
+
+
+## Accessing addon settings from CSS
+
+Userstyles can easily obtain color and numerical settings through CSS variables. They can also access settings from other enabled addons.
+
+The CSS variables always follow the `--addonId-settingId` format. Setting IDs are always converted from kebab-case to camelCase.
+
+These CSS variables are always available for all enabled addons and no manifest property is necessary to expose them. They are also synchronized with user settings without requiring a page reload.
+
+```css
+.sa-progress-bar {
+  /* Color setting */
+  background-color: var(--progressBar-bgColor);
+
+  /* Color setting with fallback */
+  border-color: var(--editorDarkMode-border, #fc7c24);
+  /* If editor-dark-mode is disabled, the fallback will be used instead */
+
+  /* Numerical setting */
+  height: calc(1px * var(--progressBar-height));
+}
+```
+
+
+## Custom CSS variables
+
+If a userstyle needs to choose between one of two values based on a background color (text contrast) or an addon setting, JavaScript isn't necessary. These conditions, among others, can be declared in the addon manifest through [customCssVariables](/docs/reference/addon-manifest/#customcssvariables), and the userstyle can simply reference that CSS variable.
+
+
+## Applying styles only inside the editor
+
+The extension automatically toggles a class name on the `<body>` element when the user enters or exits the project editor.
+
+For example, styling `<input>` elements inside and outside the editor differently:
+```css
+.sa-body-editor input {
+  /* Only applies if `addon.tab.editorMode` is `editor` or `fullscreen` */
+}
+
+body:not(.sa-body-editor) input {
+  /* Only applies if `addon.tab.editorMode` is NOT `editor` nor `fullscreen` */
+}
+```

fr/markdown/docs/develop/userstyles/best-practices.md

@@ -0,0 +1,68 @@
+---
+title: Meilleures pratiques
+description: Follow these best practices when writing or reviewing userstyles.
+---
+
+Follow these best practices when writing or reviewing userstyles.
+
+
+<!-- TODO: ## Addon dark mode support -->
+<!-- Examples on referencing CSS variables from editor-dark-mode, dark-www and scratchr2 -->
+
+
+## Internationalization
+
+### Consider languages with longer words
+
+Remember that im some languages, UI elements such as buttons may be narrower or wider.
+
+<!-- TODO: ### Supporting right-to-left languages (RTL) -->
+
+
+## Styling existing Scratch UI
+
+
+### Avoid targeting hashed class names
+
+The Scratch project editor usually contains class names that follow the `class_name_{hash}` format. For example, `green-flag_green-flag_1kiAo`.
+
+As the hashes might change in the future and may differ between Scratch forks, you should avoid using them in userstyles.
+
+{{< admonition error >}}
+```css
+/* Don't do this: */
+.green-flag_green-flag_1kiAo {
+  visibility: hidden;
+}
+```
+{{< /admonition >}}
+
+{{< admonition success >}}
+```css
+/* Do this instead: */
+[class*="green-flag_green-flag_"] {
+  visibility: hidden;
+}
+```
+{{< /admonition >}}
+
+### Avoid `!important` unless absolutely necessary
+
+If possible, use [CSS specificity](https://web.dev/learn/css/specificity/) features to make your selectors more specific, instead of using `!important`.
+<!-- This could be more detailed -->
+
+
+## Styling addon UI elements
+
+
+### Begin addon-defined class names with `sa-`
+
+{{< admonition info >}}
+We always use `kebab-case` when defining our own class names.
+{{< /admonition >}}
+
+We recommend that addon-defined class names begin with `sa-` to avoid potential name collisions with Scratch or other extensions.
+
+It is also recommended to include the addon ID (or part of it) in the class name.
+
+<!-- TODO: ### explain usage of z-index in the Scratch editor and related concepts -->

fr/markdown/docs/develop/userstyles/debugging-userstyles.md

@@ -0,0 +1,19 @@
+---
+title: Conseils de débugage
+description: Tips to easily debug userstyles, and edge cases to consider.
+---
+
+Tips to easily debug userstyles, and edge cases to consider.
+
+## Conseils
+
+### Il n'est pas toujours nécessaire de recharger l'extension
+
+Il n'est pas nécessaire de recharger l'extension en accédant à `chrome://extensions` lors du changement de source d'un fichier JavaScript ou CSS déjà existant. Dans ces cas, il suffit de recharger la page.
+
+<!-- TODO: use injectAsStyleElt for addons that need to be injected quickly to avoid flashes (such as dark modes) -->
+
+
+<!-- ## Edge cases -->
+
+<!-- None yet -->