Fakhri Azzouz

Tag: l10n

  • Theme وTemplate في واجهات ووردبريس العربية: كيف نتجنب الغموض الدلالي؟

    بصفتي مهندس تعريب (L10n Engineer) متخصص في اللغة العربية، وأستهدف بخطابي المهني أسواقاً خليجية رائدة مثل المملكة العربية السعودية والإمارات العربية المتحدة، أؤكد أن توطين واجهات المستخدم (UI Localization) يتجاوز بكثير الاستبدال الحرفي للكلمات، بل يستلزم وضوحاً سياقياً (Contextual Clarity) صارماً. في مجال توطين البرمجيات (Software Localization – L10n)، نادراً ما يثير أي تحدٍ جدلاً واسعاً مثلما تثيره المصطلحات المصدرية التي تُترجم إلى كلمة واحدة متطابقة في قاعدة المصطلحات (Glossary) العربية الافتراضية. والمثال الكلاسيكي على ذلك يبرز في أنظمة إدارة المحتوى (CMS) عند التمييز بين “Theme” و “Template”.

    في اللغة الإنجليزية، يحمل المصطلحان أدواراً تقنية متمايزة:

    • Theme: الهوية البصرية الشاملة، ولوحة الألوان، وإعدادات الخطوط المسبقة، وطبقة التنسيق المرئي.
    • Template: التخطيط الهيكلي، أو الهيكل الأساسي للصفحة (Page Skeleton)، أو المخطط الذي يحدد مواقع مكونات المحتوى.

    ومع ذلك، تُسند قواعد المصطلحات العربية (Arabic Glossaries) غالباً كلمة “قالب” لكلا المفهومين. وبينما يصف مصطلح “قالب” بدقة الهيكل الإنشائي، فإن استخدامه لكلا المصطلحين في نص واجهة واحد يخلق تعارضاً دلالياً حاداً (Severe Semantic Collision).

    التعارض الدلالي على أرض الواقع (كما يظهر في الصورة المرفقة)

    خذ بعين الاعتبار نص رسالة الخطأ الموضحة في الصورة:

    “No theme is defined for this template.”

    إذا تمت ترجمتها حرفياً باستخدام “قالب” لكلا المصطلحين، فستكون النتيجة:

    “لم يتم تحديد قالب لهذا القالب.”

    هذه الصياغة غامضة منطقياً وتقوض تجربة المستخدم (User Experience – UX)، وتترك المطورين ومسؤولي المواقع والمستخدمين النهائيين في حيرة حول ما إذا كان النظام يفتقر إلى نظام تصميم (Design System) أم إلى تخطيط هيكلي للصفحة.

    حل الغموض باعتماد مصطلح “مظهر”

    لتأسيس نصوص واجهة عربية واضحة ومهنية وواعية بالسياق، يجب علينا التمييز بوضوح بين العرض المرئي والهيكل الإنشائي. الترجمة المثلى المعتمدة لهذا النص هي:

    “لم يتم تحديد مظهر لهذا القالب.”

    من خلال حصر استخدام “قالب” بشكل صارم لمصطلح Template (الهيكل)، وتبني مصطلح “مظهر” (أو “سمة”) لمصطلح Theme (المظهر البصري/التنسيق)، فإننا نحقق إنجازات متعددة في هندسة التعريب (L10n Milestones):

    1. الدقة والوضوح الوظيفي (Precision & Functional Clarity): يدرك المستخدمون فوراً أن “مظهر” يشير إلى قواعد التصميم المرئي أو التنسيق النشط المطبق على المخطط الهيكلي الأساسي (القالب). لقد اخترنا هذا المصطلح تحديداً للتركيز على المظهر البصري (Focusing on Visual Appearance)، مما يمنع أي لبس وظيفي.
    2. تناسق قاعدة المصطلحات (Glossary Harmony): يؤدي تمييز هذه المصطلحات إلى منع تعارض مدخلات ذاكرة الترجمة (Translation Memory – TM) وتجنب الغموض المصطلحي (Terminological Ambiguity) عبر مشاريع التعريب متعددة المطورين.
    3. الاتساق عبر المنظومات التقنية (Consistency Across Ecosystems): يضمن توحيد المصطلحات عبر نواة ووردبريس (WordPress Core)، وإضافات البلوكات (Block Plugins)، وسير عمل تحرير الموقع الكامل (Full Site Editing – FSE) حفاظ الواجهات المعربة على وضوح مؤسسي راسخ.

    في توطين البرمجيات (Software Localization)، تؤثر الدقة اللغوية تأثيراً مباشراً على سهولة الاستخدام (Usability). وعندما تُدمج قواعد المصطلحات المستهدفة (Target Glossaries) مفاهيم تقنية متمايزة في مصطلح واحد، فإن تبني نهج سياقي سلطوي (Authoritative Context-First Approach) لتحسين المصطلحات يضمن بقاء الواجهة بديهية واحترافية، وهو ما يرقى لتطلعات المستخدمين في أسواقنا المستهدفة.

  • Faster l10n with GPaste

    Make Your Software Localization Workflow Faster with GPaste

    If you work in software localization, your day is all about precision, context switching, and consistency. You translate string resource files, JSON objects, PO files—and you keep repeating the same technical patterns and terms. On Linux, GPaste is a clipboard manager that can save you a lot of keystrokes and speed up your translation pipeline.

    Why Localization Pros Need a Clipboard Manager

    Localization isn’t just about translating words. You also have to preserve structure across languages. Every time you move between a TMS, a code editor, and reference glossaries, you’re copying and pasting the same kinds of snippets. A clipboard history tool lets you capture them once and pull them up whenever you need them.

    What GPaste Helps With

    • Reusing placeholders fast: Technical tokens and format specifiers like (%s) stay within reach—no retyping.
    • Keeping terminology consistent: Common UI labels, navigation items, search components, metadata tags, and localized terms stay in your history sidebar.
    • Editing across multiple files: Jump between string files and paste specialized strings, technical components, or script references like JavaScript without losing your place.

    Getting More Efficient on Linux

    Adding a clipboard history manager to your routine removes the small friction points that slow you down. It helps you stay focused on what really matters: writing natural, context-aware translations for users around the world.

  • Precision Over Simplicity in l10n

    Why Secure Custom Field Should Translate “Render” as تَصْيير, Not عرض

    Screenshot 1: Current Arabic translation using “لعرض”

    Screenshot 2: Suggested Arabic translation using “لتَصْيير”

    As an Arabic General Translation Editor (GTE), I am committed to high-impact community work for community projects. That means every string I review is not just a word choice—it is a decision that affects thousands of Arabic-speaking developers, site builders, and contributors. Recently, while localizing Secure Custom Field (SCF), I encountered a string that perfectly illustrates the tension between technical precision and user-friendly simplicity:

    “Specify the style used to render the clone field.”

    The current Arabic translation uses لعرض (“to display”). A suggested alternative uses لتَصْيير (“to render”). Both are defensible in isolation. But for SCF, the better choice is clear: تَصْيير.

    Render Is a Process, Not Just a Result

    In software engineering, “render” has a specific meaning. It describes the computational process of generating a visual output—an image, a UI element, a DOM node, a template—from code, data, or a model. تَصْيير is the technically precise Arabic term for that process. It maps directly to browser rendering, template rendering, and field rendering.

    عرض, by contrast, translates closer to “display,” “show,” or “presentation.” It focuses on the result, not the mechanism. For a general user interface, that simplification is often ideal. The average user does not need to know how the backend builds the page; they just want to know how a field will appear on the front end.

    But Secure Custom Field is not a general user interface. It is a developer tool.

    SCF Is Generally Used by Developers

    Secure Custom Field is used by developers, agencies, and technical site builders. They create custom fields, configure clone fields, write PHP, register field groups, and integrate SCF into custom themes and plugins. Even a settings label like “Specify the style used to render the clone field” is read by someone who understands the difference between rendering and displaying.

    If we translate “render” as عرض, we flatten that distinction. A developer reading the Arabic string may wonder: Is this about CSS display? Is it about front-end presentation? Or is it about the actual rendering process of the clone field? تَصْيير removes that ambiguity. It tells the developer exactly what is being configured.

    Consistency Is Community Infrastructure

    As a GTE, my responsibility goes beyond one string. I am building a glossary that will be reused across SCF and other community projects. If we translate “render” as عرض here, what happens when the next string says “render template,” “render callback,” or “render field”? Do we translate all of them as عرض? That would erase the technical meaning. Do we switch to تَصْيير later? That would create inconsistency.

    A strong glossary says: render = تَصْيير, display = عرض. This distinction helps translators, developers, and users. It is high-impact community work because it scales. One good decision today prevents hundreds of inconsistent strings tomorrow.

    The User-Friendly Argument Has Limits

    A recent analysis of this string noted that عرض is highly natural for an average user. That is true—for average users. But SCF’s primary audience is not average users. It is developers. The argument for عرض assumes a non-technical audience that does not care about backend rendering. In SCF, that assumption is wrong.

    Yes, تَصْيير may feel slightly heavier or more academic. But in a developer-facing context, that heaviness is a feature, not a bug. It signals precision. It matches the mental model of the person configuring the field. Arabic developers deserve terminology that respects their expertise.

    RTL Readability and Technical Clarity

    Some may argue that “حدد التنسيق المستخدم لتصيير حقل النسخ” is less fluid than “حدد التنسيق المستخدم لعرض حقل النسخ.” RTL readability matters, but it should not override technical accuracy. The suggested translation is perfectly readable. It is slightly more formal, but SCF is a technical product. Formal precision is appropriate.

    Moreover, Arabic technical communities have increasingly adopted تَصْيير for rendering in development contexts. Using it in SCF aligns Arabic localization with modern technical Arabic, rather than forcing a generic UI term onto a developer tool.

    The Verdict: Use تَصْيير for SCF

    For Secure Custom Field, the better translation is:

    حدد التنسيق المستخدم لتصيير حقل النسخ

    This choice preserves the technical meaning of “render,” supports glossary consistency, and respects SCF’s developer audience. عرض remains an excellent choice for user-facing strings where “display” or “show” is the intended meaning. But SCF is not that context.

    As an Arabic GTE committed to high-impact community work, I recommend changing the current translation from لعرض to لتَصْيير. It is not about being purist. It is about being precise for the people who actually use the product. When we get terminology right for developers, we strengthen the entire Arabic WordPress ecosystem. That is community work worth doing.

  • Ellipsis in WordPress

    The Ellipsis in WordPress: Why … Beats ... Every Time

    If you’ve spent any time developing for WordPress, you’ve probably encountered this seemingly trivial question: should you use three dots (...) or the proper ellipsis character (…) in your user-facing strings?

    It might look like a minor stylistic choice, but in the WordPress ecosystem, this decision has real implications for code quality, localization, and professional polish. The WordPress core team has made their position clear—and here’s why you should follow their lead.

    The Problem with Three Dots

    Three periods might be the quickest thing to type, but they’re a typographic compromise. They’re the plain-text fallback, not the real thing.

    WordPress does have a built-in function called wptexturize() that automatically converts three periods into a proper ellipsis in post content. However, you should never rely on this for translatable strings. Here’s why:

    • Inconsistent application: wptexturize() isn’t guaranteed to run in every context—JavaScript strings, HTML attributes, or certain admin screens may bypass it entirely.
    • Unpredictable results: What works in one context might break in another, leading to visual inconsistencies across your plugin or theme.

    The WordPress Core Standard

    The WordPress core team has been systematically replacing three dots with proper ellipses for years.

    In Changeset 24207 (May 2013), core contributor SergeyBiryukov made a sweeping update across multiple files with the message: “Use ellipsis instead of three dots”. This changeset touched 16 different files, removing instances of ... from translatable strings throughout the admin.

    Then came Changeset 33939 (September 2015), with the explicit message: “Round 2 of: We should use ellipses … / … instead of three dots/periods … e.g Loading… not Loading…”.

    The message is clear: WordPress core developers actively prefer the proper ellipsis character.

    The Best Practice: Use … in Translatable Strings

    For WordPress localization (l10n), the recommended approach is to use the actual ellipsis character directly in your translatable strings:

    // ✅ Recommended
__( 'Loading…', 'my-text-domain' );
__( 'Continue reading…', 'my-text-domain' );

// ❌ Avoid
__( 'Loading...', 'my-text-domain' );
__( 'Continue reading...', 'my-text-domain' );

    Why This Matters for Localization

    1. Translators need full control

    Different languages have different conventions for ellipses. Some languages use different characters, some add spaces, and some have specific rules about when and how to use them. By including the ellipsis as part of the translatable string, you give translators complete control over how it appears in their language.

    2. Context is everything

    An ellipsis on a button (“Save As…”) serves a different purpose than one indicating truncated text (“Read more…”). Keeping the ellipsis with its specific string allows translators to handle these nuances appropriately.

    3. Avoids fragmented strings

    Hard-coding punctuation outside of translatable strings can lead to awkward phrasing in other languages where word order differs.

    … vs … vs …

    You have three options for representing an ellipsis:

    OptionExampleBest Used For
    Unicode character…Translatable strings (recommended)
    HTML entity (named)…HTML templates where character encoding might be unclear
    HTML entity (numeric)…RSS feeds or contexts where named entities may break

    For translatable strings, the actual Unicode character … is the clear winner. It’s simple for translators to see and work with, and it aligns with WordPress core practices.

    What About Escaping?

    A common concern is whether esc_html() or similar escaping functions will handle the ellipsis character correctly.

    Good news: esc_html() passes the ellipsis character through unchanged because it’s not a character that needs escaping for HTML. It’s completely safe.

    However, if you use the HTML entity … inside a translatable string and then apply esc_html(), you might end up with literal … displayed to users if the string is double-escaped or used in certain contexts.

    Summary: The Bottom Line

    PracticeVerdict
    __( 'Loading...' )❌ Avoid—three dots are a typographic compromise
    __( 'Loading…' )⚠️ Risky—may break with escaping or in certain contexts
    __( 'Loading…' )✅ Best practice—clean, translatable, and core-approved

    References for Further Reading

    Final Word

    Using the proper ellipsis character … in your WordPress translatable strings isn’t just about looking professional—it’s about following core conventions, respecting translators, and writing more robust code.

    The WordPress core team has done the heavy lifting of standardizing this practice. All that’s left is for you to adopt it.

    Next time you type ... in a translatable string, stop and use … instead. Your users—and your translators—will thank you.

    Have thoughts on this? Drop a comment below or reach out on Twitter. And if you found this helpful, consider sharing it with your fellow WordPress developers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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