Fakhri Azzouz

Tag: l10n

  • الربطُ أم الارتباطات؟ رحلة تعريب‏

    الربطُ أم الارتباطات؟.. رحلةٌ في تعريب مصطلح “Bindings” داخل ووردبريس

    أثناء عملي اليومي على تعريب نظام ووردبريس، وتحديداً في أثناء مراجعة ملفات ترجمة إحدى الإضافات المتعلقة بالتكامل مع الخدمات السحابية، وقفتُ أمام سؤال وجّهه إليّ أحد المطوّرين، بدا في ظاهره بسيطاً، لكنه حمل في طيّاته إشكاليةً لغويةً تقنيةً عميقة، إذ قال: “ما رأيكَ بـ ‘الارتباطات’ ترجمةً لمصطلح ‘Bindings’؟”

    ابتسمتُ في نفسي، لأن هذا السؤال تحديداً يُعدّ أحد المزالق التي تسقط فيها الترجمة الآلية، بل وحتى ترجمة المترجمين البشر حين يمرّون على النصوص البرمجية من دون تثبّت. والحقيقة أن كلمة “الارتباطات” هي ترجمة حرفية للمصطلح في المعجم العام، لكنها في سياق علوم البرمجة تصبح ترجمة خادعة، وذلك لأن “الربط” هنا يُعبّر عن فعلٍ أو عمليةٍ (Process) تربط بين عنصرين برمجيين؛ كربط دالة بمتغيّر، أو ربط مصدر بيانات بعنصر تحكّم في الواجهة. في حين أن “الارتباط” يحمل في دلالته معنى العلاقة المجرّدة أو الصلة المنطقية، وهو ما لا يعبّر عن الآلية التقنية التي تجري خلف الكواليس.

    وسرعان ما تلاه سؤال آخر، قال فيه: “حسناً، فما هو جمع ‘ربط’؟”. كان جوابي المباشر أن الجمع الصرفي الأقرب هو “رُبُوط”، غير أنني تريّثتُ قليلاً عند هذه النقطة، وتساءلتُ: هل يصحّ لي أن أكتب هذه الكلمة في واجهة مستخدم ووردبريس؟ تخيّل معي مدير موقع غير مختصّ تقنياً يقرأ جملة من قبيل: “تم حذف الربوط”! سيبدو الأمر غريباً على مسامعه، بل قد يظنّ أن هناك خطأً نحواً، أو أن الكلمة مقحمة من لهجة لا تتناسب مع النصّ الرسمي للنظام.

    وهنا تحديداً تبرز حِرفَة المختصّ في مجال التوطين، تلك التي تتجاوز الترجمة الحرفية إلى هندسة النصّ وفق مقاييس الاستخدام الواقعي.

    لماذا اخترتُ صياغة “عمليات الربط” وتجنّبتُ “ربوط”؟

    في جميع الترجمات التي أقدّمها لعملاء ووردبريس؛ سواءٌ كانوا مطوّرين أو أصحاب مواقع، أعتمد وبشكل ثابت صياغة “عمليات الربط” (عمليات + ربط) كمرادف جمعي للمصطلح. وهذا الخيار لم يأتِ جزافاً، بل استند إلى مجموعة من المبررات العملية واللغوية:

    1. الوضوح بالنسبة إلى المستخدم النهائي: إن إضافة كلمة “عمليات” تمنح المستخدم انطباعاً فورياً بأن هناك إجراءاتٍ تقنيةً تُنفَّذ في الخلفية. فعندما يقرأ مدير الموقع عبارة “جميع عمليات الربط”، فإنه يدرك أنّ الأمر يتعلّق بتكوينات أو مهام تقنية قابلة للحذف أو التعديل، لا أنّه بصدد “علاقات” غامضة بين الجداول.
    2. الانسجام مع المنهجية المُتّبعة في تعريب كبريات الشركات: إذا راجعتَ ترجمات كل من مايكروسوفت وأبل، أو حتى المشروع العالمي لتعريب ووردبريس نفسه، ستجدهم يُفضّلون صياغة المصادر التي تعبّر عن العمليات بهذا الأسلوب؛ فيقولون “معالجة البيانات” لا “بيانات”، و”عمليات التحديث” لا “تحديثات”، وذلك للحدّ من الالتباس وجعل النصّ أكثر احترافية.
    3. تجنّب الخلط القاتل مع مصطلحات أخرى: فلو اعتمدنا “الارتباطات” ترجمةً للمصطلح، لدخلنا في متاهةٍ من الالتباس لا تنتهي، وذلك لأنّ مستخدمي الويب بشكلٍ عام، وأصحاب مواقع ووردبريس بشكلٍ خاص، ألفوا كلمة “رابط” و”روابط” للدلالة على عناوين الصفحات والوصلات التشعبية (URLs). لذا، حين يقرأ مدير الموقع عبارة “تم حذف الارتباطات”، لن يخطر بباله أنّ الأمر يتعلق بعمليات ربط برمجية، بل سيفزع معتقداً أن الروابط الدائمة لموقعه أو وصلات التنقل الداخلية قد انقطعت أو أُزيلت! إنّ استخدام “عمليات الربط” يزيح كل هذا الغموض دفعةً واحدة، ويُبقي النصّ في إطاره التقني المحايد الواضح.

    تطبيق عملي: جملة صغيرة لكنها كبيرة

    في الأسبوع الماضي، بينما كنتُ أترجم رسالة تأكيد لإحدى الإضافات المتكاملة مع جداول بيانات جوجل، كان النصّ الإنجليزي كالتالي:

    “All bindings removed. Your Google Sheets are untouched.”

    كانت الترجمة الآلية السريعة ستعطي نتيجةً حرفية، مثل: “تمت إزالة جميع الربوط. جداول بيانات جوجل الخاصة بك لم تُلمَس”. ولكنني خرجتُ بالصياغة التالية، التي أرسلتها إلى العميل واعتمدها بعد مناقشة قصيرة:

    “تمت إزالة جميع عمليات الربط. ولم تتأثر جداول بيانات جوجل الخاصة بك.”

    ودعني أوضح لك أسباب اختياري لكلّ لفظة هنا:

    • “جميع عمليات الربط” بدلاً من “الربوط”: لأن المستخدم يرى في لوحة التحكّم قائمةً بهذه العمليات، وحذفها يعني حذف إعداداتها وتفكيك تكويناتها، لا حذف “كيانات” مادّية. وهذه الصياغة أشدّ أُنساً للنفس، وأكثر وضوحاً للفهم من الجمع المباشر.
    • “لم تتأثر” بدلاً من “لم تُلمَس” أو “سليمة”: لأن الفعل “تأثّر” هو الأقرب للتعبير الدارج في الرسائل النظامية الاحترافية. تخيّل رسالة من تطبيق بنكي تقول “حسابك لم يتأثر”، فهي أكثر طمأنةً واحترافية من عبارة “حسابك سليم” التي قد تحمل بعض الغموض.

    كلمة أخيرة إلى الزملاء المختصين

    التوطين في ووردبريس ليس مجرد استبدال كلمات من لغة إلى أخرى، بل هو هندسةٌ للنصّ، وغربلةٌ للكلمات بحيث يشعر المستخدم العربي بأن الواجهة صُنعت من أجله هو، لا أنها مجرّد شاشة عولمت بطريقة آلية. أنصح نفسي وإيّاكم باختبار الترجمات على مستخدمين حقيقيين، وألّا نتردّد في طرح السؤال الأهم: لو كنتُ مدير موقع لا يعرف الإنجليزية، فهل ستفيدني هذه الرسالة وتطمئنني؟

    شخصياً، تجنّبتُ استخدام “ربوط” في جميع مشاريعي الأخيرة، ونصيحتي لكم هي الاعتماد على “عمليات الربط” أو “إعدادات الربط” بحسب السياق، والابتعاد تماماً عن “الارتباطات” في النصوص البرمجية الحاسوبية. فلنثق بحاسة السمع العربية أكثر من ثقتنا بالمعجم وحده، فالمتلقّي العربي يسمع الكلمة ويحسّ بوقعها قبل أن يُمعن في تحليلها النحوي.

    وختاماً، أدعوكم لمشاركتي تجاربكم: هل واجهتم مواقف مشابهة مع مصطلحات برمجية أخرى؟ وما هي ترجمتكم المفضّلة لمصطلح “Binding” في مشاريعكم التوطينية؟

  • Code as Context for l10n

    Why WordPress Demands “مخطّط المستند” Over Legacy Translations

    In software localization, a string in isolation is a trap. When translating a massive platform like WordPress, looking at a spreadsheet of isolated English phrases often leads to “safe” but clunky translations. The ultimate source of truth is never the glossary—it is the source code.

    For years, the Arabic localization for “Document Outline” has been ملخص عناوين المستند (literally: Summary of document headings). Born from an era where translators felt the need to heavily explain UI features to users (a process called explicitation), this string is wordy, descriptive, and ultimately outdated.

    As we look toward modern WordPress UI paradigms, it is time to standardize this string to مخطّط المستند. To understand exactly why this update is necessary, we don’t need to debate linguistics—we just need to look at the code.

    The Reference Code: A Window into the UI

    Let’s examine the exact file where this string lives in the Gutenberg block editor: wp-includes/js/dist/editor.js, specifically within the TableOfContentsPanel component.

    Here is the structural blueprint of that panel:

    JavaScript

    // ... [Lines 49560 - 49617 omitted for brevity] ...
<div className="table-of-contents__wrapper" role="note" aria-label={__("Document Statistics")}>
    {/* Renders Counts: Words, Characters, Time to read, Headings, Paragraphs, Blocks */}
</div>

{ headingCount > 0 && (
    <>
        <hr />
        <h2 className="table-of-contents__title">{__("Document Outline")}</h2>
        <DocumentOutline
            onSelect={onRequestClose}
            hasOutlineItemsDisabled={hasOutlineItemsDisabled}
        />
    </>
)}
// ... [Line 49630] ...

    By reading this snippet, the context transforms the way we must approach the translation. Here is how the reference code guides us to a vastly superior Arabic localization.

    1. The Code Proves It’s a Structure, Not a “Summary”

    Look at the logic in the code. The panel is divided into two distinct sections. The top half is strictly for Document Statistics (Words, Characters, reading time). This top section acts as the actual summary of the document’s contents.

    Below the <hr /> (horizontal rule), we see the Document Outline. If we keep the legacy translation ملخص عناوين المستند (Summary of headings), we create a semantic clash. We are placing a “summary” directly underneath actual statistical summaries.

    The <DocumentOutline/> component rendered here is a navigational tree—a structural skeleton that lets users jump between header blocks. مخطّط means “plan,” “map,” or “outline.” By using مخطّط المستند, we accurately tell the user they are looking at a structural map, differentiating it cleanly from the statistics above it.

    2. The Original File Path Reveals Architectural Intent While the bundled distribution code lives in editor.js, line 49560 provides a crucial breadcrumb to the original, uncompiled source code: // packages/editor/build-module/components/table-of-contents/panel.mjs.

    This file path is a L10n goldmine. It explicitly identifies that this UI element belongs to the table-of-contents component. A Table of Contents is inherently a navigational map of a document’s hierarchy; it is never a summary of the text itself. By organizing the code under table-of-contents, the core engineering team is signaling clear structural intent.

    Translating this feature as a ملخص (summary) directly contradicts the architectural blueprint of the software. Conversely, مخطّط (outline/map) perfectly echoes the navigational purpose of a Table of Contents, ensuring the Arabic string aligns with the foundational logic of the Gutenberg editor.

    3. The <h2> Tag Demands Brevity

    Notice the HTML element wrapping our string:

    <h2 className="table-of-contents__title">{__("Document Outline")}</h2>

    This string is not explanatory text; it is a section heading (<h2>). In UI design, headings must be punchy, scannable, and instantly recognizable.

    • Legacy: ملخص عناوين المستند (3 words, visually heavy)
    • Proposed: مخطّط المستند (2 words, crisp and standard)

    Users do not read software interfaces; they scan them. A three-word, overly descriptive heading slows down the user’s cognitive parsing. مخطّط المستند functions perfectly as a quick, scannable title.

    4. Spatial Constraints of the Sidebar Panel

    The component name is TableOfContentsPanel. In the WordPress editor, this panel is a narrow sidebar or a popover menu. UI real estate is highly restricted.

    When a multi-word string like ملخص عناوين المستند is crammed into a narrow sidebar, it risks truncation (e.g., ملخص عناوين ا...) or awkward line breaks, especially on mobile views. The source code reveals the physical constraints of the UI, proving that the shorter, more compact مخطّط المستند is a functional necessity to preserve the design layout.

    5. Aligning with Industry Standards

    As localization specialists, consistency across the digital ecosystem is one of our primary goals. When users switch between Microsoft Word, Google Docs, Apple Pages, and various web-based CMS platforms, they shouldn’t have to learn a new vocabulary for the exact same tool.

    Major tech giants have already recognized the need for concise, structural terminology:

    • Google Docs currently utilizes مخطّط المستند for its outline feature.
    • Microsoft Word uses similar structural terminology, like جزء التنقل (Navigation Pane) or مخطط المستند (Document Map in older versions).

    By updating to مخطّط المستند, we align our product with the established mental models of millions of Arab users. We stop forcing them to translate our unique legacy jargon and instead speak the language they already know.

    Conclusion: Translating for the Future

    WordPress is a constantly evolving ecosystem. With modern iterations of the block editor, the UI is becoming cleaner, faster, and more minimalist. Our Arabic localization must evolve with it.

    Relying on the source code changes a translator from a mere linguist into a UI/UX advocate. The code at editor.js:49618 explicitly tells us that “Document Outline” is a compact, structural heading housed within a narrow panel. By dropping the outdated, hand-holding explicitation, observing UI boundaries, and adopting the industry standard مخطّط المستند, we respect the developer’s design and ultimately provide a more native, professional experience for the Arab WordPress user.

  • When two words in English become one in Arabic

    When “Optimizations” and “Improvements” Become the Same Word: An Arabic Localization Puzzle

    Imagine you’re translating a changelog for a sleek software product. The release note reads:

    Front-end Optimizations improvements

    As a localization specialist, you pause. In English, “optimizations” and “improvements” carry subtly different weights: one hints at performance tuning, the other at overall quality boosts. But in Arabic, both words often funnel into a single term: تحسينات (tahseenaat).

    Put them together literally, and you get a tongue-twisting redundancy:
    تحسينات تحسينات الواجهة الأمامية
    “Improvements improvements of the front end.” Not exactly the crisp, professional tone your client expects.

    This kind of linguistic collision happens more often than we admit, and how we handle it can make or break the user experience. Let me walk you through my thought process and the solutions I’d offer.

    First, understand the intent

    Before reaching for a thesaurus, I always ask: What is this string really trying to say?
    Does “Front-end Optimizations” refer to a specific named feature, module, or settings tab in the product? Or is it a general description of performance work? The answer steers the translation.

    Here are the three strategies I’d use, depending on the context.

    Option 1: The natural, flowing approach (usually my go-to)

    If the goal is simply to tell users “we made the front end even better,” I merge the concepts gracefully. Instead of forcing two nouns to coexist, I introduce a word like performance or additional to bridge the gap:

    • تحسينات إضافية لأداء الواجهة الأمامية
      Additional improvements to front-end performance
    • المزيد من تحسينات الواجهة الأمامية
      More front-end optimizations

    This reads naturally and avoids the awkward repetition while keeping the message intact.

    Option 2: The exact technical approach

    When “Front-end Optimizations” is the official label of a feature, dashboard card, or settings panel, I can’t just dissolve it. The user might need to locate that exact term in the UI. In that case, I keep the term distinct by using a synonym pair:

    • تطويرات على تحسينات الواجهة الأمامية
      Enhancements to Front-end Optimizations

    Here, تطويرات (tatawweeraat – developments/enhancements) takes the role of “improvements,” while تحسينات stays frozen as the feature name. It’s a bit clunky, but it preserves the technical mapping.

    Option 3: Action-oriented, changelog-style

    Release notes often benefit from a punchy verbal noun at the start. This turns a static label into a dynamic promise:

    • تعزيز تحسينات الواجهة الأمامية
      Boosting Front-end Optimizations

    Short, active, and unmistakable. It treats “Front-end Optimizations” as a noun phrase you’re amplifying, not as a redundant couple.

    The real secret? Always ask for context

    This tiny phrase taught me—again—that even two English words can collapse into one in another language. The fix isn’t a dictionary swap; it’s detective work. Is “Front-end Optimizations” the official name of a specific settings tab in your software, or is it just a general description of the update? The right Arabic translation hangs entirely on that answer.

    Next time you encounter a deceptively simple string like “Optimizations improvements,” take a breath, decode the intent, and choose the strategy that keeps the message clear—and your client’s interface elegant.

    Have you faced a similar localization puzzle where two distinct terms became one in your target language? I’d love to hear how you solved it. Let’s swap war stories in the comments.

  • Mass Editing in l10n

    Mastering Technical Localization: A Case Study on Mass Editing “Purge” in Arabic

    In the world of software localization, consistency is not just a luxury; it is a necessity. When users interact with a technical interface, they rely on predictable terminology. If a button says “Purge” in one menu and “Clear” in another, but the underlying action is similar, confusion arises.

    This article explores a practical workflow for mass-editing and improving Arabic localization, using the term “Purge” (translated as “محو”) as a case study. We will look at how to leverage filtering tools and rapid .po file editing with simple text editors to ensure speed and accuracy.

    The Challenge: “Purge” in a Technical Context

    The word “Purge” in computing—specifically regarding caching—implies a forceful removal of data. It is stronger than “Clear” or “Delete.”

    In Arabic, translators often oscillate between:

    • مسح (Mas’h): Wiping/Clearing (Common for “Clear Cache”).
    • حذف (Hadhf): Deleting.
    • محو (Mahw): Erasing/Obliterating (A strong, precise term for “Purge”).

    As seen in the provided screenshot, the translation team has settled on “محو” (Mahw) for “Purge” and “محو ذاكرة التخزين المؤقت” for “Purge Cache.” This is a solid choice because it distinguishes the action from a simple “Clear.”

    Step 1: Leveraging the Filter and Search

    The screenshot shows a translation management interface, GlotPress. The most powerful feature here is the Search and Filter combination.

    1. The Search Bar: At the top, the user has searched for purge. The system highlights the term in yellow/orange within the “Original string” column. This immediately visualizes every instance where the term appears.
    2. The Filter: Notice the link “Current Filter (12)”. This indicates that the view is currently restricted to a specific subset of strings.
    3. The Result Count: The top bar shows 1/14. This means there are 14 total instances of “purge” in this web page.

    Why this matters: Instead of scrolling through 325 strings (as shown in “All (325)”), the specialist can focus entirely on the 14 relevant strings. This is the first step in mass editing.

    Step 2: Analyzing Context and Grammar

    Before mass editing, we must ensure the translation fits the grammatical context. Arabic is a highly inflected language, meaning words change form based on gender and number.

    Looking at the screenshot:

    • Imperative/Noun: “Purge SG Cache” is translated as محو ذاكرة التخزين المؤقت SG. Here, “Purge” is treated as a verbal noun (Masdar). This is correct for UI buttons.
    • Passive Verb: In the first long string: “…once it is purged…”. The translation is “…بمجرد محوها…” (once it [feminine] is erased).
      • Specialist Note: The translator correctly identified that “it” refers to “cache” (ذاكرة – feminine) or the implied object, and added the suffix “ها” (ha) to “محو”. This shows high attention to detail.

    Step 3: The Rapid Mass Edit Workflow (Text Editor + .po File)

    While the web interface is great for review, editing strings one by one is slow and inefficient. The fastest method for mass editing is exporting the .po file, editing it with a simple text editor, and re-importing it to GlotPress.

    Here is the recommended workflow:

    3.1 Export the .po File

    From GlotPress, navigate to your project and export the Arabic translation file (ar.po). This file contains all your translations in a simple, human-readable format.

    3.2 Open with a Text Editor

    You don’t need expensive CAT tools. Simple, powerful text editors work perfectly:

    • VS Code (Visual Studio Code) – Free, powerful search/replace
    • Text Editor by Gnome Project

    3.3 Perform Mass Find and Replace

    This is where the magic happens. Let’s say you want to ensure consistency for “Purge” → “محو”:

    Example Scenario:
    You notice that some translations use “مسح” while others use “محو” for “Purge.” You want to standardize everything to “محو”.

    In your text editor:

    1. Open Find/Replace (Ctrl+H or Cmd+H)
    2. Search for: msgstr "مسح ذاكرة التخزين المؤقت"
    3. Replace with: msgstr "محو ذاكرة التخزين المؤقت"
    4. Replace All

    Handling Context Variations:
    Looking at the screenshot, you might need to handle:

    • msgstr "محو ذاكرة التخزين المؤقت" (Purge Cache)
    • msgstr "محو يدوي لذاكرة التخزين المؤقت" (Manual Cache Purge)
    • msgstr "محو ذاكرة التخزين المؤقت SG" (Purge SG Cache)

    With a text editor, you can quickly review all instances and make bulk changes while maintaining the different grammatical forms.

    3.4 Validate the .po File

    Before importing back:

    • Most text editors will show syntax highlighting for .po files
    • Check that all msgid (English) and msgstr (Arabic) pairs are intact
    • Ensure no quotation marks are broken
    • Verify that Arabic text is properly encoded (UTF-8)

    3.5 Import Back to GlotPress

    1. Go to your GlotPress project
    2. Navigate to Import Translations
    3. Upload your edited ar.po file
    4. Choose the import options:
      • Import existing translations as suggestions (safer, requires review)
      • Overwrite existing translations (faster, but be careful!)
    5. Click Import

    Pro Tip: For large projects, import as “suggestions” first, then use GlotPress’s bulk approval feature to approve all changes at once after a quick review.

    Step 4: Handling Acronyms and Technical Terms

    The screenshot provides excellent examples of handling technical terms that should not be translated:

    • “SG Cache”: Translated as ذاكرة التخزين المؤقت SG. The acronym “SG” (likely SiteGround) is kept in English. This is correct.
    • “wp-cron”: Kept as wp-cron in the Arabic text. This is crucial because translating technical function names breaks the software logic.
    • “URLs”: Translated as رابط (links/URLs). This is a good localization choice, making it understandable for Arabic users while keeping the number “200”.

    When doing mass edits in a text editor, you can use negative lookaheads in regex to avoid replacing technical terms. For example, ensure you don’t accidentally replace “purge” inside code comments or function names.

    Benefits of the Text Editor Workflow

    1. Speed: What takes 30 minutes of clicking in GlotPress takes 2 minutes in a text editor
    2. Consistency: One find/replace ensures every instance is updated
    3. Flexibility: Use regex for complex patterns
    4. No Dependencies: No need for expensive CAT tool licenses
    5. Version Control: You can track changes in the .po file using Git
    6. Reusability: Save your find/replace patterns for future projects
    Editing a .po file using Gnome text editor

    Common Pitfalls to Avoid

    ⚠️ Always backup your .po file before mass editing!

    ⚠️ Don’t break the .po syntax:

    • Keep msgid and msgstr on separate lines
    • Maintain quotation marks
    • Don’t remove the msgid "" entries

    ⚠️ Watch for context:

    • “Purge” as a verb vs. noun may need different Arabic forms
    • Plural forms in Arabic are complex (singular, dual, plural)
    • Ensure gender agreement (محوها vs محوه)

    ⚠️ Test after import:

    • Always verify a few strings in GlotPress after importing
    • Check that special characters display correctly
    • Ensure no HTML entities are broken

    Conclusion

    Mass editing localization is not just about speed; it is about uniformity and efficiency. By using the filter function to isolate terms like “purge” (as seen in the screenshot), a specialist can review all instances quickly.

    However, the real time-saver is the export → text editor → import workflow. This method allows you to:

    • Make hundreds of changes in seconds
    • Maintain perfect consistency across your project
    • Work offline without platform limitations
    • Use powerful search patterns (regex) for complex edits

    For Arabic localization specifically, where grammatical variations are common, this workflow ensures that “Purge” is always “محو” and “Purged” is grammatically correct throughout the entire project.

    Key Takeaway: Filter to identify the scope, export the .po file, use a simple text editor for mass find/replace operations, and import back to GlotPress. This workflow transforms hours of manual work into minutes of efficient editing while maintaining the highest quality standards.

  • Beyond the Glossary: Context-Driven Arabic Translations for ‘Author’ and ‘Parent’ in WordPress

    Beyond the Glossary: Context-Driven Arabic Translations for ‘Author’ and ‘Parent’ in WordPress



    In WordPress Arabic localization, the choice between كاتب and مُطوِّر for translating "author" is strictly context-driven. The official WordPress Arabic glossary provides a clear baseline, but real-world usage requires nuance.

    Official Rule (WordPress Glossary)

    Author → كاتب
    في سياق المحتوى الكتابي مثل مقال، صفحة، تعليق..الخ

    كاتب is the default, approved translation for “author” when referring to the person who wrote content within WordPress (posts, pages, comments).

    When to Use Each Term

    TermUse When…Example ContextsWhy
    كاتبReferring to the writer of content (posts, pages, comments, custom post types)كاتب المقالة، عرض جميع مقالات الكاتب، كاتب التعليقMatches the glossary; aligns with Arabic UX expectations for content attribution.
    مُطوِّرReferring to the creator of a plugin or themeمُطوِّر الإضافة، مُطوِّر القالبمُطوِّر implies “originator/creator of a substantial work” – used outside content authorship. Is also synonym with developer.

    Critical Distinction in WordPress Core

    WordPress uses contextual strings (_x()) to disambiguate. Always check the msgctxt:

    // Content authorship → كاتب
_x( 'Author', 'post author' );           // → كاتب

// Plugin/theme creator → مُطوِّر
/* translators: %s: plugin author name */
__( 'By %s', 'my-plugin' );              // Context: plugin header → مُطوِّر

// Theme author (official glossary)
'Theme Author' → 'مُطور القالب'          // Note: glossary uses مُطوِّر, not مؤلف

    🚫 Common Pitfalls to Avoid

    MistakeWhy It’s WrongCorrection
    Using مؤلف for post authorsSounds overly formal; breaks consistency with WP admin UIUse كاتب
    Using كاتب for plugin authorsUnderstates the technical/creative roleUse مُطوِّر (preferred) or مؤلِّف
    Ignoring msgctxtLeads to inconsistent translations across contextsAlways check context in .pot files
    Translating “Author” without contextAmbiguous; may be post author, plugin author, or book authorRequest context from developers or use glossary defaults

    ✅ Quick Reference Decision Tree

    Is "author" referring to…?
│
├─► A person who wrote a post/page/comment? → كاتب
│
├─► The creator of a plugin/theme? → مُطوِّر (glossary-preferred) 
││
└─► Uncertain? → Default to كاتب + flag for review

    In WordPress Arabic localization, the choice between أب and الأصل for translating "parent" is strictly context-driven. The WordPress Arabic translation team maintains a consistent convention to avoid ambiguity in UI, code, and documentation.

    Note: we use أم instead of الأب, that is “mother” instead of “father” when translating “parent page” as “page is feminine” in Arabic.

    Here’s the practical breakdown:

    ✅ Use أب when:

    ContextExample TranslationWhy
    Parent/Child Themesالقالب الأبMirrors the technical parent/child metaphor used in WP theme inheritance. Pairs naturally with القالب الابن.
    Code/Developer Contextsملف القالب الأب, دوال القالب الأبUsed in dev docs, hooks, or CLI output where the familial metaphor is preserved for clarity.
    Term/Theme/Plugin Inheritance UIتحديث القالب الأب Matches how WP core handles theme relationships.
    Pageصفحة أمWe use أم (mother) as page is feminine

    ✅ Use الأصل when:

    ContextExample TranslationWhy
    Hierarchical Content (Categories, Custom Post Types)الصفحة الأصل, التصنيف الأصل, الأصل (dropdown label)الأصل implies “root/source/base” in Arabic UX. It’s the standard for content trees.
    Menu Structureالعنصر الأصل, الأصلMenus use الأصل to denote top-level items in nested lists.
    Taxonomy/Relationship UIاختيار الأصل, بدون أصلAvoids biological connotations; focuses on hierarchy origin.

    🔍 How WordPress Enforces This

    WordPress uses contextual translation functions to distinguish these cases. In the source code, you’ll find:

    _x( 'Parent', 'child theme' );        // → الأب
_x( 'Parent', 'theme parent' );      // → القالب الأب
_x( 'Parent', 'menu parent' );       // → الأصل

    Always check the msgctxt (message context) in .pot files. It’s the single source of truth.

    Conclusion

    Navigating these subtleties in WordPress Arabic localization demands more than a quick glossary lookup—it calls for deliberate, context-aware investigation. When doubt arises, always check the message context (msgctxt) in source files, cross-reference previously approved translations, and inspect the surrounding code to confirm meaning. Filtering a term across the entire project helps you maintain a consistent, precise translation that respects both the official glossary and real-world user expectations.