فيما يخص الاقتراح الأول، إضافة رموز اللغات إلى أسماء الملفات، فلقد تم العمل به في كثير من المواقع (سفنكس Sphinx). منتِجوا المواقع الثابتة يستعملونه في مختلف الحالات. (هوڭو Hugo ||جيكل Jekyll).
ڭت تيكست و سفنكس يشكلان نظاما معقدا و يتطلب مجهودا لفهمه. إضافة مزيد من اللغات إلى الملف للقراءة (README) قد تسهل هذه العملية.
إذا أخذنا [الملف الأصلي]، فلنقسمه إلى نصفين، [إسم الملف] + [الملحق] ([FILENAME + EXTENSION]). نضيف الملحق بعد النقطة (.) الأخيرة، لنتولى بأسماء تحتوي على عدة نقط. ينتمي [رمز اللغة] إلى واحد من الرموز الاعتيادية (en, fr, ar, jp ،إلخ).
نبدأ بالبحث عن [إسم الملف] . [رمز اللغة] . [الملحق] ([EXTENSION] + [LANGUAGE CODE] + [FILENAME]). و يُستعمل إذا وُجد.
إذا لم يوجد، فنستعمل [الاسم الأصلي]
و فيما يخص (للقراءة | README)، فخيارنا الأول هو البحث عن ( للقراءة.[رمز اللغة].README.[LANGUAGE CODE].md | md )، فيمكن لمن يستعملان المنتوج أن تضيفا ( للقراءة.README.fr.md | md.fr ) للتكلف باللغة الفرنسية، أو ( للقراءة.README.ar.md | md.ar) للتكلف باللغة العربية. يمكن تطبيق رمز اللغة بموقع مثل <crates.io>.
يمكن بناء ملف TOML للمكتبة كما يلي:
[package]
name = "hello_world"
description = "hi"
[package.ar]
name = "مرحبا بالعالم"
description = "أهلا"
إذا لم يحدد رمز اللغة. يمكن استعمال الاختيار اللذي لا يحمل رمزا. مواصفة اللغة لا تستعمل أي مفتاح فرعي.
Français
La première suggestion, où l’on applique des codes aux noms de fichiers, est utilisée dans plusieurs endroits (Sphinx: https://sphinx-doc.org/en/master/usage/advanced/intl.html). Les générateurs de sites statiques utilisent beaucoup cette approche (Hugo: https://gohugo.io/content-management/multilingual/ || Jekyll: https://github.com/kurtsson/jekyll-multiple-languages-plugin).
Gettext/Sphinx est un système complexe, et n’est probablement pas pour les débutants. Par contre, des fichiers README multilingues seraient utiles.
Pour [FICHIER ORIGINAL] on brise l’entrée en deux parties, [FILENAME] + [EXTENSION]. [EXTENSION] contient uniquement le texte après le dernier ., pour gérer les fichiers avec plusieurs . Dans leur nom. [LANGUAGE CODE] est un des codes languages typiques de ISO 639-1 (en, fr, ar, jp, etc.).
- On cherche en premier pour
[NOM DE FICHIER] . [CODE DE LANGUAGE] . [EXTENSION]. Si c’est trouvé, on utilise ce fichier.
- Sinon, on utilise
[FICHIER ORIGINAL].
Pour README.md, the nom par défaut est toujours README.[CODE DE LANGUE].md. Les usagers peuvent ajouter README.fr.md pour supporter le français, ou README.ar.md pour l’arabe. Les codes de language peuvent être déterminés par des sites comme crates.io.
Pour les fichiers Crate TOML, de façon similaire:
[package]
name = "hello_world"
description = "hi"
[package.fr]
name = "bonjour_le_monde"
description = "salut"
Si le language n’est pas spécifié, on utilise la valeur par défaut spécifiée dans la configuration sans code de language. Aucun code de language n’est utilisé comme sous-clef dans la spécification.
svenska
Det första förslaget att applicera språkkoder i filnamn används av många (Sphinx: https://www.sphinx-doc.org/en/master/usage/advanced/intl.html). Statiska sidgeneratorer använder också ofta denna metod (Hugo: https://gohugo.io/content-management/multilingual/ || Jekyll: https://github.com/kurtsson/jekyll-multiple-languages-plugin).
Gettext/Sphinx är ett mycket invecklat system och är kanske inte det bästa att börja med, men stöd för flerspråkiga README filer skulle hjälpa.
För [URSPRUNGLIGT FILNAMN] så delas det upp i två bitar, [FILNAMN] + [FILÄNDELSE]. [FILÄNDELSE] är bara texten efter den sista . i filnamnet för att kunna hantera flera . i filnamnet. [SPRÅKKOD] är en av de vanliga språkkoderna (en, fr, ar, jp, etc.).
- Börja med att leta efter
[FILNAMN] . [SPRÅKKOD] . [FILÄNDELSE]. Hittad? Använd filen.
- Om inte, använd
[URSPRUNGLIGT FILNAMN].
För README.md är standardinställningen att leta efter README.[SPRÅKKOD].md. Användare kan lägga till README.fr.md för att stödja franska eller README.ar.md för att stödja arabiska. Språkkod kan ställas in per websida som crates.io.
Med en Crate TOML file, som:
[package]
name = "hello_world"
description = "hi"
[package.sv]
name = "hello_world"
description = "hej"
Om ingen språkkod är specificerad används standardinställningen från den utan språkkod. Ingen språkkod används som undernyckel i specifikationen.
Nederlands
Het eerste voorstel om taalcodes toe te passen in bestandsnamen wordt op veel plaatsen al zodanig gebruikt (Sphinx: https://www.sphinx-doc.org/en/master/usage/advanced/intl.html). Statische website generatoren gebruiken dit ook alom. (Hugo: https://gohugo.io/content-management/multilingual/ || Jekyll: https://github.com/kurtsson/jekyll-multiple-languages-plugin).
Gettext/Sphinx is een erg gecompliceerd systeem en waarschijnlijk een van de lastigste om mee te starten. Het ondersteunen van meertalige READMEs zou echter behulpzaam zijn.
Breek [ORIGINELE BESTANDSNAAM] in twee delen, [BESTANDSNAAM] + [EXTENSIE]. [EXTENSIE] is alleen de tekst die na de laatste punt komt, om met bestandsnamen met meerdere punten overweg te kunnen. [TAALCODE] is een van de typische taalcodes (en, nl, ar, jp, enz.).
- Begin door te zoeken naar
[BESTANDSNAAM] . [TAALCODE] . [EXTENSIE]. Gevonden? Zoja, gebruik deze.
- Als dat niet lukt, gebruik dan
[BESTANDSNAAM].
Voor README.md zoekt de standaard naar README.[TAALCODE].md. Gebruikers kunnen een README.fr.md toevoegen voor Frans, of README.ar.md voor Arabisch. Taalcodes kunnen worden ingesteld door een website zoals crates.io.
Voor een Crate TOML bestand is het vergelijkbaar:
[package]
name = "hello_world"
description = "hi"
[package.nl]
name = "hallo_wereld"
description = "hoi piepeloi"
Als de taalcode niet opgegeven is wordt de standaardvariant gebruikt zonder taalcode. In de specificatie wordt geen taalcode gebruikt als ondersleutel.
Deutsche
Der erste Vorschlag, Sprachcodes am Ende des Dateinamens zu geben, wird bereits in sehr vielen Werkzeugen verwendet (Sphinx: https://www.sphinx-doc.org/en/master/usage/advanced/intl.html). Auch in Statischer Seitengenerierung ist es stark in Verwendung (Hugo: https://gohugo.io/content-management/multilingual/ || Jekyll: https://github.com/kurtsson/jekyll-multiple-languages-plugin).
Gettext/Sphinx ist ein sehr komplexes System und höchstwahrscheinlich nicht ideal für AnfängerInnen. Mehrsprachige README Unterstützung würde allerdings sehr hilfreich sein.
Die [ORIGINALE DATEI] wird dafür in zwei Teile geteilt, [DATEINAME] + [ERWEITERUNG]. [ERWEITERUNG] ist nur nach dem letztem ., bei Dateinamen mit mehreren .. [SPRACHCODE] ist einer der typischen Sprachcodes (en, fr, ar, jp, etc.).
- Zuerst wird für
[DATEINAME] . [SPRACHCODE] . [ERWEITERUNG] gesucht. Falls gefunden, wird die Datei verwendet.
- Falls nicht wird
[ORIGINALE DATEI] verwendet.
Für README.md wird standardmäßig immer nach README.[SPRACHCODE].md gesucht. NutzerInnen können dann README.fr.md hinzufügen um Französich zu unterstützen oder README.ar.md um Arabisch zu unterstützten. Der Sprachcode wird dann durch eine Webseite wie crates.io gewählt.
Für die Crate TOML Datei ähnlich:
[package]
name = "hello_world"
description = "hi"
[package.de]
name = "hallo_welt"
description = "hallo"
Falls der Sprachcode nicht spezifiziert ist, wird standardmäßig einfach jener ohne Sprachcode verwendet. Sprachcodes werden nicht als Subschlüssel in der Spezifikation verwendet.
English
The first suggestion of applying language codes to file names is used in a lot of places (Sphinx: https://www.sphinx-doc.org/en/master/usage/advanced/intl.html). Static site generators also use this extensively (Hugo: https://gohugo.io/content-management/multilingual/ || Jekyll: https://github.com/kurtsson/jekyll-multiple-languages-plugin).
Gettext/Sphinx is a very involved system and probably not the best to get started. But multi-lingual README support would be helpful.
For [ORIGINAL FILE] break it into 2 pieces, [FILENAME] + [EXTENSION]. [EXTENSION] is only text after very last ., to handle multi . file name. [LANGUAGE CODE] is one of typical language codes (en, fr, ar, jp, etc.).
- Start by searching for
[FILENAME] . [LANGUAGE CODE] . [EXTENSION]. Found? Use file.
- If fail, use
[ORIGINAL FILE].
For README.md, the default is always looking for README.[LANGAUGE CODE].md. Users can add README.fr.md to support French, or README.ar.md to support Arabic. The language code can be passed down through the website like crates.io.
For a Crate TOML file, similar can be done in the file:
[package]
name = "hello_world"
description = "hi"
[package.es]
name = "hola_mundo"
description = "hola"
If a language code is not specified, just use default from one with no language code. No language code is used as sub-key in the specification.
I think a good first step is supporting [FILENAMEPREFIX] . [COUNTRY CODE] _ [LANGUAGE CODE] . [EXTENSION] as a way to have certain files for a specific country/language. There are ISO standards (1, 2) for the country and language codes to make it easy for everyone to agree. This will work well for READMEs and is easy to scale for most projects.
".po" files - Gettext-style -- translation is a much bigger thing. A lot of documentation translators are used to do this thanks to FSF and Linux Foundation-style projects, which use this frequently for strings being output from various projects. I am unsure if this is the best for documentation itself, because documentation is largely prose and therefore there would be more text being replaced than just certain strings. This is why I think having Language Code / Country Code file lookup and use would be a far better alternative here, but I'd leave that to better experts. 
A short bit on English Supremacy in Tech: what much of this thread argued for is that we should make it as difficult as possible for anyone to interface with the start of my post. They would not want a dedicated translation feature to "keep things closer to English" or "prevent Balkanization", which is exactly what making translation non-standard and difficult would do as @Manishearth has explained so beautifully. I had thought this to be taken for granted for the Rust community, but it is entirely worth noting:
- The first "serious" Rust Communities came from Korea and Sweden.
- One of the most famous posts legitimizing Rust was a Korean's post on the Rust Reddit, not someone working in an English speaking country.
- Rust's biggest users exist outside of English countries (PingCAP, Embark, Parity, etc).
Forcing people to speak English does not create magical creatures who suddenly absorb English better. It throws out good programmers willing to do hard work and don't want to put up with an ecosystem that constantly tells them to Learn English Or Piss Off. The same feeling many of you reading got from staring at the Arabic above and having to find one of the drop-downs so you could understand is the same feeling many of us have to deal with, in perpetuity, in many programming language communities. What some advocated for -- the equivalent of a "no support for translation dropdowns on this post at all" policy -- is just suppression of every other language with English Only Because There's No Support For Internationalization. It is a crabs-in-a-bucket, race-to-the-bottom style of community management and it absolutely sucks.
We can either write our READMEs in some language and have everyone grafting ad-hoc translation support (or none at all because we make it difficult and thus have people just give up on sharing in other written languages or leaving the community).
OR. We can provide standard, well-defined controls for doing a better job of serving multiple people and increasing not only Rust's but Rust's libraries/crates appeal and ability to be shared, with everyone.
I prefer -- and this community should absolutely prefer -- the latter.
) I would likely involve myself in both.