From fc74008c468662af74e8eceadd0de98c3b2f68bf Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Sun, 12 Oct 2025 16:03:53 +0900 Subject: [PATCH] Add initial draft for language use --- text/0005-language.md | 54 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 text/0005-language.md diff --git a/text/0005-language.md b/text/0005-language.md new file mode 100644 index 0000000..62622e1 --- /dev/null +++ b/text/0005-language.md @@ -0,0 +1,54 @@ +- Start Date: 2025-10-12 +- RFC PR: N/A +- STD Issue: N/A +- Severity: MUST + +# Uzbek as the Primary Language of Communication + +To ensure clarity and foster a welcoming, inclusive environment for all Uzbek developers, all formal communication within the FLOSS Uzbekistan community **MUST** be in Uzbek language. This includes, but isn't limited to, official RFCs, community announcements, project documentation, and discussions on the main GitHub repositories and chat platforms. + +### Motivation + +The primary goal of the FLOSS Uzbekistan community is to serve and empower the local Uzbek IT community. While English is a global standard in the tech world, using Uzbek as the main language for official communications and documentation makes the community more accessible to developers who are more comfortable in their native tongue. This approach lowers the barrier to entry, encourages broader participation from within Uzbekistan, and helps to build a strong, self-sufficient local developer ecosystem. It also fosters a unique community identity and promotes the use of Uzbek in technical contexts. + +### Detailed Design + +To implement this guideline, the following actions **MUST** be taken: + +- **Official Communications:** All new RFCs, pull requests for new features, project readmes, and other official documentation **MUST** be written in Uzbek. + +- **GitHub Repositories:** All project and organizational descriptions, issue templates, and contributing guidelines on GitHub **MUST** be in Uzbek. + +- **Chat Platforms:** The primary language for discussions in main Telegram groups and channels and other community chats **MUST** be Uzbek. While occasional use of English or other languages for clarification is acceptable, the core of the conversation should remain in Uzbek. + +- **Project Specifics:** For projects or libraries that are intended for a global audience, English documentation can be provided in addition to the required Uzbek version. A common practice is to have a `README.md` in Uzbek and a `README_en.md` for English, or to use a translation tool to maintain multiple versions. + +### Guide-Level Explanation + +For community members and contributors: + +- When creating a new RFC or a substantial pull request, write your proposal and documentation in Uzbek. + +- If you're creating a new project, make sure the project's `README.md` and `CONTRIBUTING.md` files are in Uzbek. + +- In our main community chats, use Uzbek to communicate with others. + +- If you're a maintainer, politely remind contributors to use Uzbek for their official submissions. If a pull request or RFC is submitted in another language, it may be closed with a polite request to resubmit in Uzbek. + +For community leaders and maintainers: + +- Actively enforce this guideline in your respective communities and projects. + +- Review and merge RFCs and pull requests that adhere to the Uzbek language requirement. + +- Ensure that all new official community resources are created in Uzbek first. + +Unresolved Questions + +- How will we handle contributions from non-Uzbek speakers who wish to participate? Should we create a separate channel for them, or encourage the use of translation tools? + +- Will the use of technical terms borrowed from English be standardized, or will we create new Uzbek terms for them? + +### Future Possibilities + +As the community grows, we may explore the creation of a formal lexicon of Uzbek technical terms to be used in all official communications. This could be a collaborative project between the community and linguistic experts to ensure consistency and clarity. Additionally, a future RFC might address the creation of separate English-language channels or documentation for specific projects with a wider global scope. \ No newline at end of file