تعدد اللغات في تطبيقات WinForms/WPF ── الممارسة العملية لملفات resx وتجميعات الأقمار الصناعية وتبديل الثقافة

«نريد استخدام التطبيق نفسه في الفروع الخارجية أيضاً»، «ازداد عدد الموظفين الناطقين بلغات أجنبية في موقع المصنع فنريد الشاشات بالإنجليزية أيضاً» — تعدد اللغات في تطبيقات سطح المكتب على Windows مطلب بسيط في ظاهره، لكن ما إن تشرع فيه حتى تتوالى نقاط الحيرة: «كيف نستخدم resx؟»، «توجد عدة طرق في WPF ولا نعرف أيها الصحيح»، «هل يمكن تبديل اللغة أثناء التشغيل؟».

في هذا المقال، وبافتراض تطبيقات أعمال مبنية بـ WinForms/WPF، نرتّب بالترتيب الذي يكثر التردد عنده في العمل: أساس التوطين في .NET (الثقافة والرجوع الاحتياطي للموارد)، وآلية resx وتجميعات الأقمار الصناعية، والطرق الواقعية حسب كل إطار عمل، والتبديل أثناء التشغيل، حتى النقاط فيما وراء النصوص (التنسيق والتخطيط وRTL).

1. الخلاصة أولاً (جدول القرار)

طريقة تعدد اللغات تتحدد بمزيج إطار العمل والمتطلبات.

نكتب الخلاصة أولاً.

• CurrentCulture (التنسيق) وCurrentUICulture (لغة الموارد) شيئان مختلفان. هذا التمييز أساس تصميم تعدد اللغات كله (الفصل 2).
• كيان الموارد «موارد اللغة المحايدة + تجميعات أقمار صناعية حسب اللغة»، والرجوع الاحتياطي تلقائي. يُبحث بالترتيب ja-JP ← ja ← المحايد، فإن نقصت ترجمة لا يسقط التطبيق بل يُعرض بلغة الافتراضي².
• في WinForms الحل العملي الجمع بين أسلوب المصمم (Localizable = true) وأسلوب resx المشترك. الشاشات بأسلوب المصمم، ومربعات الرسائل والنصوص المشتركة تُقرَّب إلى resx مشترك (الفصل 4).
• أسلوب LocBaml الوارد في الدليل الرسمي لـ WPF لا يعمل في .NET (Core)¹. الممارسة الحالية الخيار الأول resx + x:Static (أو الربط) (الفصل 5).
• تبديل اللغة أثناء التشغيل اجعل «يسري عند التشغيل التالي» خيارك الأول. لأن موارد الشاشة المعروضة لا تُستبدل تلقائياً (الفصل 6).
• ترجمة النصوص نصف تعدد اللغات فقط. النصف الباقي متابعة التخطيط لطول النص بعد الترجمة، وتنسيق التاريخ والأرقام، والخطوط، ودعم اللغات التي تُكتب من اليمين إلى اليسار (RTL) (الفصل 7).

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 23، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. الأساس ── الفرق بين CurrentCulture وCurrentUICulture

لثقافة .NET (إعداد النطاق الثقافي) خاصيتان مختلفتا الدور³.

يمكن ضبط الاثنتين مستقلتين. مزيج مثل «الشاشة إنجليزية، لكن التاريخ والعملة بتنسيق اليابان» (متطلب شائع في تطبيقات أعمال لناطقين بلغات أجنبية داخل اليابان) يُعبَّر عنه طبيعياً بـ CurrentUICulture = en وCurrentCulture = ja-JP.

القيمة الافتراضية لكلتيهما تأتي من إعداد نظام التشغيل، فنقطة الانطلاق «إن لم تفعل شيئاً اتبع نظام التشغيل». عند تبديل اللغة صراحة للتطبيق كله، لا تضبط حسب الخيط بل استبدل القيمة الافتراضية.

using System.Globalization;

// 以降に作られるすべてのスレッドの既定カルチャを差し替える
// (UIスレッド生成前=Application.Run前に実行する)
CultureInfo.DefaultThreadCurrentUICulture = new CultureInfo("en"); // リソース言語
CultureInfo.DefaultThreadCurrentCulture = new CultureInfo("ja-JP"); // 書式

الإسناد إلى Thread.CurrentThread.CurrentUICulture يسري على ذلك الخيط فقط. في تطبيق أعمال يعبر الخيوط بـ async/await أو معالجة خلفية، تغيير القيمة الافتراضية كلها بـ DefaultThreadCurrentUICulture / DefaultThreadCurrentCulture أقل عرضة للحوادث³.

لاحظ أن تنسيق السجلات وإخراج الملفات والتكامل بين الأنظمة لا تُتبع فيه ثقافة المستخدم بل يُثبَّت على CultureInfo.InvariantCulture. تصميم تنسيق التاريخ عموماً في تصميم التاريخ والوقت والمنطقة الزمنية في تطبيقات الأعمال.

3. آلية الموارد ── resx وتجميعات الأقمار الصناعية والرجوع الاحتياطي

توطين .NET نموذج «محور وأشعة». موارد اللغة الافتراضية (المحايدة) تُضمَّن في تجميعة الأصل، وموارد كل لغة تُفصل في DLL آخر اسمه تجميعة قمر صناعي⁴.

بعد البناء يصير تكوين الإخراج لـ resx حسب اللغة كما يلي.

MyApp.exe                     ← 本体(ニュートラルリソースを含む)
MyApp.dll
ja/MyApp.resources.dll        ← 日本語のサテライトアセンブリ
en/MyApp.resources.dll        ← 英語のサテライトアセンブリ

عند التشغيل يبحث مدير الموارد انطلاقاً من CurrentUICulture بالترتيب ثقافة محددة (ja-JP) ← ثقافة محايدة (ja) ← الافتراضي (الأصل)². بفضل هذا الرجوع الاحتياطي التلقائي، إن نقصت ترجمة واحدة لا يسقط التطبيق بل يُعرض نص اللغة الافتراضية. وبالعكس، «شاشة يفترض أنها إنجليزية تختلط فيها يابانية في مواضع» علامة نقص ترجمة، ويمكن استخدامها كمنظور اختبار (الفصل 8).

في العمل ثبّت النقطتين التاليتين.

• التصريح بأي ثقافة هي اللغة الافتراضية بسمة NeutralResourcesLanguage يلغي عبث البحث عن قمر صناعي عند الثقافة الافتراضية، ويوضّح نهاية الرجوع الاحتياطي⁴.
• تجميعة القمر الصناعي «لا تعمل إلا بالتوزيع مع الأصل» لذلك يلزم تضمين مجلدات اللغة في تصميم المثبّت أو التوزيع بالنسخ (الفصل 8).

طريقة التصريح بـ NeutralResourcesLanguage اثنتان حسب شكل المشروع. أولاً الشكل القديم الذي يحمل AssemblyInfo.cs يدوياً (افتراضي .NET Framework).

// Properties/AssemblyInfo.cs
using System.Resources;

// 本体アセンブリに埋め込んだリソースが日本語であることを宣言する
[assembly: NeutralResourcesLanguage("ja-JP")]

في مشروع نمط SDK (افتراضي .NET 5 فما بعد) يُولَّد AssemblyInfo.cs عند البناء، لذلك تُحدَّد الخاصية في ملف المشروع.

<!-- MyApp.csproj -->
<PropertyGroup>
  <NeutralLanguage>ja-JP</NeutralLanguage>
</PropertyGroup>

من Visual Studio يمكن الإعداد نفسه في «اللغة المحايدة للتجميعة» ضمن [الحزمة] > [عام] في خصائص المشروع. لاحظ أن كتابة الاثنين في مشروع نمط SDK تُحدث تعريفاً مزدوجاً للسمة فيصير خطأ بناء (CS0579). اجعل أحدهما فقط.

4. الممارسة في WinForms ── أسلوب المصمم وأسلوب resx المشترك

لـ WinForms أسلوبان، وفي العمل يُجمع بينهما.

4.1 الشاشات بأسلوب المصمم (Localizable = true)

في خصائص النموذج اجعل Localizable تساوي true، وبدّل خاصية Language إلى اللغة المستهدفة (مثال: الإنجليزية) ثم حرّر Text للتسميات والأزرار، فيولّد Visual Studio تلقائياً resx حسب اللغة مثل Form1.en.resx⁵. الخطوات بترتيب التشغيل كما يلي.

1. افتح النموذج في المصمم، وانقر النموذج نفسه لا عنصر التحكم (جزء الخلفية) لاختياره
2. في نافذة الخصائص (F4) اجعل Localizable تساوي True. عند هذه النقطة تُكتب نصوص عناصر التحكم وأحجامها ومواضعها في Form1.resx للغة الافتراضية
3. في نافذة الخصائص نفسها بدّل Language من «(القيمة الافتراضية)» إلى اللغة المستهدفة (مثال: English)
4. في تلك الحالة حرّر Text وحجم التسميات والأزرار وموضعها. يُحفظ التحرير في Form1.en.resx ولا يتغيّر resx اللغة الافتراضية
5. بعد انتهاء العمل أعد Language إلى «(القيمة الافتراضية)»

إن واصلت تغيير التخطيط المعتاد ناسياً الخطوة 5، دخل التغيير في resx اللغة قيد التحرير لا اللغة الافتراضية، فيُكتشف لاحقاً بشكل «موضع الزر غريب في اليابانية فقط». في الفريق الذي يستخدم أسلوب المصمم شارك نسيان إعادة Language أولاً.

قوة هذا الأسلوب أن ليس النص فقط بل حجم عنصر التحكم وموضعه يُحفظان حسب اللغة. مشكلة مثل «登録» اليابانية صارت «Register» فخرجت من الزر يمكن ضبطها حسب اللغة على المصمم. في المقابل يولد تكلفة صيانة: يزيد resx بعدد اللغات × عدد النماذج، ويلزم التحقق من كل اللغات عند كل تغيير لتخطيط النموذج. إن كان متوقعاً ازدياد عدد اللغات، قدّم تكوين شاشة «لا ينهار حتى بلا ضبط» بإجراء جانب التخطيط التالي (الفصل 7).

4.2 الرسائل والنصوص المشتركة بأسلوب resx المشترك

النصوص المستخدمة من الشيفرة مثل نص مربع الرسائل وحوار التأكيد وعرض شريط الحالة تُجمع في Resources.resx المشترك للمشروع، وتُضاف حسب اللغة ملفات مثل Resources.en.resx. من resx تُولَّد فئة مُنمَّطة تلقائياً، فيمكن الرجوع من الشيفرة بلا خطأ كتابة في المفتاح.

// 生成された型付きクラス経由で参照する。
// 返る文字列はCurrentUICultureに応じて自動で切り替わる
MessageBox.Show(
    Properties.Resources.ConfirmDeleteMessage,
    Properties.Resources.ConfirmTitle,
    MessageBoxButtons.YesNo);

القاعدة الأهم هنا عدم كتابة النص الذي يُعرض للمستخدم مباشرة في الشيفرة. جهد تعدد اللغات لا يُنفق على إدخال الآلية بل على «استرداد النصوص المكتوبة مباشرة المتناثرة». حتى في مرحلة التشغيل بلغة واحدة، قيمة التمرير عبر resx هنا.

5. الممارسة في WPF ── اجعل resx خيارك الأول بدل LocBaml

نرتّب أولاً المصطلحات الظاهرة في هذا الفصل.

تعدد اللغات في WPF مجال تختلط فيه المعلومات بسهولة. دليل الوثائق الرسمية يحمل أسلوباً يضبط UICulture في ملف المشروع ليولّد موارد BAML ثم يُدخل الترجمة بأداة LocBaml، لكن LocBaml أداة عيّنة خاصة بـ WPF على .NET Framework، ولا تعمل في WPF على .NET (Core)¹. اعتبرها أسلوباً لا يُختار جديداً اليوم.

الخيار الأول في العمل الرجوع من XAML إلى أسلوب resx المشترك نفسه كما في WinForms.

<!-- resxのアクセス修飾子をPublicにしたうえでx:Staticで参照する -->
<Window xmlns:res="clr-namespace:MyApp.Properties"
        Title="{x:Static res:Resources.MainWindowTitle}">
    <Button Content="{x:Static res:Resources.SaveButton}" />
</Window>

ميزة هذا الأسلوب أن آلية الموارد (تجميعات الأقمار الصناعية والرجوع الاحتياطي) مشتركة تماماً مع WinForms، فيمكن إدارة النصوص مركزياً حتى في حل مختلط. x:Static مرجع ثابت يُحل عند التشغيل، فإن لزم التبديل أثناء التشغيل يُطوَّر إلى ربط + إشعار بالتغيير (الفصل 6).

في جانب XAML، اضبط أيضاً xml:lang على عنصر الجذر حتى تعمل ميزات WPF المعتمدة على اللغة مثل القطع بالشرطة والرجوع الاحتياطي للخطوط وعرض الأرقام بشكل صحيح¹.

حكم الاختيار بين WinForms وWPF نفسه في جدول قرار التمييز بين WinForms / WPF / WinUI.

6. تبديل اللغة أثناء التشغيل ── اجعل «يسري عند التشغيل التالي» خيارك الأول

في متطلب اختيار اللغة من شاشة الإعدادات، اختر توقيت السريان من خطتين.

• الخطة أ: السريان عند التشغيل التالي (موصى بها). احفظ اللغة المختارة في ملف إعداد، واضبط DefaultThreadCurrentUICulture قبل Application.Run عند التشغيل (في WPF قبل تشغيل Application). التنفيذ بسيط، ولا تقع بنيوياً أعطال مرافقة لإعادة بناء الشاشة (فقدان بيانات قيد الإدخال، التسجيل المزدوج لمعالج الأحداث وغيرها).
• الخطة ب: السريان الفوري. حتى بعد تغيير CurrentUICulture نصوص الشاشة المعروضة لا تُستبدل تلقائياً. في أسلوب مصمم WinForms أعد التطبيق على النماذج المفتوحة بـ ComponentResourceManager.ApplyResources، وفي WPF ورّد السلسلة بربط + إشعار بالتغيير. في الحالين يصير البناء شرطاً أن «كل الشاشات تدعم إعادة تطبيق الموارد».

في تطبيقات الأعمال كثيراً ما لا تتناسب تكلفة تنفيذ الخطة ب واختبارها مع تكرار تغيير اللغة (عادة مرة عند الإدخال)، فيُنصح بـ جعل الخطة أ افتراضياً، والخطة ب فقط حين تكون لازمة حقاً كمتطلب. موضع حفظ إعداد اللغة إعداد لكل مستخدم فناسب ما تحت %LOCALAPPDATA%. حكم موضع الإعداد في جدول القرار في الممارسة العملية لإدارة الإعداد في تطبيقات Windows للأعمال.

6.1 حفظ إعداد اللغة وقراءته (تنفيذ الخطة أ)

الخطة أ تكفيها شيفرة بهذا القدر. موضع الحفظ مجلد تصنعه تحت Environment.SpecialFolder.LocalApplicationData (= %LOCALAPPDATA%).

using System;
using System.Globalization;
using System.IO;

internal static class LanguageSetting
{
    private static readonly string Dir = Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
        "MyCompany", "MyApp");

    private static readonly string FilePath = Path.Combine(Dir, "language.txt");

    // 設定画面で選ばれた言語を保存する(例: "en", "ja-JP")
    public static void Save(string cultureName)
    {
        Directory.CreateDirectory(Dir);
        File.WriteAllText(FilePath, cultureName);
    }

    // 起動時、Application.Run(WPFならApplication起動)より前に呼ぶ。
    // 保存が無い・壊れている場合は何もしない = OSの表示言語に従う
    public static void ApplyOnStartup()
    {
        if (!File.Exists(FilePath)) return;

        var name = File.ReadAllText(FilePath).Trim();
        if (name.Length == 0) return;

        try
        {
            CultureInfo.DefaultThreadCurrentUICulture = new CultureInfo(name);
        }
        catch (CultureNotFoundException)
        {
            // 未知のカルチャ名。設定を無視してOSの表示言語のままにする
        }
    }
}

النقطة جعل حالة عدم وجود ملف الإعداد تعني «اتبع نظام التشغيل». عند التشغيل الأول أو عند تلف الملف لا يتوقف باستثناء، بل يسقط كما هو إلى القيمة الافتراضية لـ CurrentUICulture (الفصل 2).

6.2 الشكل الأدنى عند تنفيذ الخطة ب (السريان الفوري)

نستعرض هيكل التنفيذ احتياطاً إن لزم السريان الفوري بحكم المتطلب. في الحالين الشرط أن «كل الشاشات تركب هذه الآلية» لا يتغيّر.

إن استخدمت أسلوب المصمم في WinForms (Localizable = true)، أعد تطبيق resx حسب اللغة على النموذج المفتوح بـ ComponentResourceManager.

using System.ComponentModel;
using System.Globalization;
using System.Windows.Forms;

public partial class MainForm : Form
{
    // 言語切り替え後、開いている各フォームで呼ぶ
    public void ApplyCurrentLanguage(CultureInfo culture)
    {
        CultureInfo.DefaultThreadCurrentUICulture = culture;
        CultureInfo.CurrentUICulture = culture; // 実行中のUIスレッドにも効かせる

        var resources = new ComponentResourceManager(GetType());

        // フォーム自身(タイトル・サイズ)は "$this" というキーで保存されている
        resources.ApplyResources(this, "$this");
        ApplyRecursive(Controls, resources);
    }

    private static void ApplyRecursive(
        Control.ControlCollection controls, ComponentResourceManager resources)
    {
        foreach (Control control in controls)
        {
            resources.ApplyResources(control, control.Name);
            ApplyRecursive(control.Controls, resources); // 入れ子のパネルも辿る
        }
    }
}

هذا التكرار لا يتتبع إلا Control، لذلك عناصر القوائم وأشرطة الأدوات (ToolStripItem ليس Control) تحتاج تتبّع ToolStrip.Items على حدة وتطبيق المعالجة نفسها. «القائمة وحدها لا تتغيّر لغتها» سببه هذا.

في WPF استبدل x:Static (صيغة تقرأ القيمة مرة) بربط، وألقِ إشعار تغيير عند تبديل اللغة.

using System.ComponentModel;
using System.Globalization;
using System.Windows.Data;

// 文字列の供給元。XAMLからはこのインスタンスにバインドする
public sealed class Loc : INotifyPropertyChanged
{
    public static Loc Instance { get; } = new Loc();

    private Loc() { }

    // インデクサー経由でresxのキーを引く。見つからなければキー名をそのまま返す
    public string this[string key] =>
        Properties.Resources.ResourceManager.GetString(key, CultureInfo.CurrentUICulture) ?? key;

    public event PropertyChangedEventHandler PropertyChanged;

    public void ChangeLanguage(CultureInfo culture)
    {
        CultureInfo.DefaultThreadCurrentUICulture = culture;
        CultureInfo.CurrentUICulture = culture;

        // インデクサー全体の変更通知。Binding.IndexerName の中身は "Item[]"
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(Binding.IndexerName));
    }
}

<!-- resxのアクセス修飾子はInternalまたはPublicにしておく -->
<Window xmlns:loc="clr-namespace:MyApp">
    <Button Content="{Binding Path=[SaveButton], Source={x:Static loc:Loc.Instance}}" />
</Window>

الفرق عن المرجع المباشر بـ x:Static في الفصل 5 أنه ربط فيستطيع تلقّي إشعار التغيير فحسب. آلية resx وتجميعات الأقمار الصناعية في الخلف هي نفسها، لذلك عند الانتقال لاحقاً من الخطة أ إلى الخطة ب لا حاجة لإعادة صنع الموارد، والعمل يصير استبدال طريقة المرجع في XAML.

7. تعدد اللغات فيما وراء النصوص ── التخطيط والتنسيق والخطوط وRTL

حتى بعد انتهاء الترجمة، يبقى نصف تعدد اللغات.

• تمدد التخطيط. النص بالمعنى نفسه يختلف طوله كثيراً حسب اللغة («保存» اليابانية ← «Speichern» الألمانية). تخطيط الإحداثيات الثابتة والحجم الثابت ينهار عند كل ترجمة، لذلك في WinForms الطريقة الموجَّهة رسمياً الجمع بين TableLayoutPanel وAutoSize لتخطيط يتابع طول النص⁶. نظام تخطيط WPF متغيّر أصلاً، فيكفي تجنّب تثبيت العرض لمعظم الحالات. صمّم أيضاً مع إجراءات منع الانهيار في بيئة DPI العالية (دليل دعم DPI العالي في WinForms ودليل دعم DPI العالي في WPF) حتى لا يحدث رجوع.
• تنسيق التاريخ والأرقام والعملة. عرض الشاشة اتركه لـ CurrentCulture، وقلّل تثبيت ToString("yyyy/MM/dd") الخاص من شيفرة الشاشة. وبالعكس ثبّت الملفات والسجلات وبيانات التكامل على InvariantCulture (الفصل 2).
• الخطوط. تحقق أن حروف اللغة المستهدفة موجودة في الخط. عند إضافة الصينية (المبسطة/التقليدية) أو الكورية، قد يصير شكل الحرف غير طبيعي إن بقي تحديد خط موجَّه لليابانية (مشكلة أشكال CJK). تجميع تحديد خط الواجهة في موضع واحد يسهّل التغيير عند إضافة لغة.
• اللغات التي تُكتب من اليمين إلى اليسار (RTL). في دعم العربية والعبرية يلزم، فوق ترجمة النص، عكس الشاشة يميناً ويساراً. WinForms يُضبط بخاصيتي RightToLeft / RightToLeftLayout، وWPF بخاصية FlowDirection. دعم RTL إن «أُضيف لاحقاً» صار مراجعة لكل الشاشات، فإن احتمل دخوله في اللغات المستهدفة فأدرجه في المتطلبات من البداية.
• النص داخل الصور والأيقونات. النص المحروق في صورة لا يتبدل بآلية الموارد. تجنّب الصور ذات النص، واجعل التكوين صورة + تسمية نص، فهذا آمن.

حكم تصميم الواجهة عموماً أيضاً في جدول قرار تصميم UX لتطبيقات Windows.

8. التشغيل ── تسليم الترجمة وكشف النقص والتوزيع

أخيراً جانب التشغيل بعد قيام الآلية.

• أرفق السياق عند تسليم الترجمة. تسليم مفتاح resx والنص الأصلي وحدهما لا يثبّت جودة ترجمة نصوص قصيرة مثل «OK» و«開く». التعامل الواقعي جدول مقابلة (جدول بيانات وغيره) يضيف إلى المفتاح والأصل والترجمة «الشاشة المعروضة والاستخدام»، ثم عكسه إلى resx بعد الاستلام.
• اكتشف نقص الترجمة بالرجوع الاحتياطي. بنتيجة الرجوع الاحتياطي للموارد يظهر نقص الترجمة بشكل «اختلاط اللغة الافتراضية في شاشة تلك اللغة»². ضع في CI تحققاً بسيطاً (سكريبت أو شيفرة اختبار) يقابل قائمة مفاتيح resx حسب اللغة مع resx المحايد، فيُكشف آلياً قبل الإصدار.
• ضمّن تجميعات الأقمار الصناعية في التوزيع. إن لم تُوزَّع مجلدات اللغة مثل ja/ وen/ كما هي، رجعت تلك اللغة وحدها احتياطياً وصارت حالة «ترجمنا لكن لا يسري». تسرّب مجلد اللغة عند النسخ اليدوي حادث نمطي، فأدرج بنية المجلدات كما هي في المثبّت (MSI/MSIX وغيرها). في توزيع ClickOnce تُدرج تجميعات الأقمار الصناعية لكل اللغات في النشر افتراضياً⁷. حكم طريقة التوزيع كلها في كيفية اختيار طريقة توزيع تطبيقات Windows.

الخلاصة

تعدد اللغات في تطبيقات سطح المكتب يقوم على آلية ناضجة هي resx وتجميعات الأقمار الصناعية، والآلية نفسها ليست صعبة. ما يفصل النجاح في العمل هو تصميم يميّز CurrentCulture عن CurrentUICulture، وانضباط بعدم كتابة النص المعروض للمستخدم مباشرة، وتخطيط يحتمل طول النص بعد الترجمة، وتمييز المتطلب «هل التبديل الفوري لازم حقاً». في WPF لا تنجرف وراء معلومات أسلوب LocBaml القديم، والحل العملي الحالي البناء على أساس resx.

اختيار الطريقة وتقدير نطاق التأثير عند إضافة تعدد اللغات لاحقاً إلى تطبيق قائم، ودعم تعدد اللغات للشاشات والتقارير وبيانات التكامل تمهيداً للنشر في فروع خارجية، كثيراً ما تحتاج حكماً مع النظر في حالة قاعدة الشيفرة، فإن ترددت فاستشرنا.

مقالات ذات صلة

• جدول قرار التمييز بين WinForms / WPF / WinUI
• جدول قرار تصميم UX لتطبيقات Windows
• تصميم التاريخ والوقت والمنطقة الزمنية في تطبيقات الأعمال
• دليل دعم DPI العالي في WinForms
• دليل دعم DPI العالي في WPF
• ليس appsettings.json وحده ── الممارسة العملية لإدارة الإعداد في تطبيقات Windows للأعمال
• كيفية اختيار طريقة توزيع تطبيقات Windows (MSI / MSIX / ClickOnce / xcopy / محدّث ذاتي)
• آلية ملف تعريف مستخدم Windows

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم تعدد اللغات في تطبيقات WinForms/WPF وتنفيذه، ومع الاستشارة التقنية لاختيار الطريقة وترتيب نطاق التأثير عند إضافة تعدد اللغات لاحقاً إلى تطبيق قائم.

• تطوير تطبيقات Windows
• الاستشارة التقنية ومراجعة التصميم
• التواصل معنا

المراجع

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل يمكن إضافة دعم تعدد اللغات لاحقاً إلى تطبيق قائم صُنع باليابانية وحدها؟

نعم يمكن، لكن معظم العمل ليس «إدخال آلية الموارد» بل «حصر النصوص المكتوبة مباشرة في الشيفرة واستبدالها». يلزم جرد ليس نصوص الشاشات فقط، بل أيضاً مربعات الرسائل والسجلات ورسائل الاستثناء والتقارير وحتى النصوص المعروضة المخزَّنة في قاعدة البيانات، والحجم يتحدد بتشتت النصوص أكثر من عدد الشاشات. إن حرصت من مرحلة التطوير الجديد على تمرير النصوص التي تُعرض للمستخدم عبر resx فقط، انخفضت تكلفة تعدد اللغات مستقبلاً بدرجة كبيرة جداً.

هل يجوز الاكتفاء بالترجمة الآلية؟

للأدوات الداخلية أو الحلول المؤقتة البدء بالترجمة الآلية أمر واقعي. لكن تطبيقات الأعمال تكثر فيها الكلمات القصيرة في الأزرار والقوائم (مثل «登録» أو «取消»)، وهذا مجال ترتفع فيه نسبة خطأ الترجمة الآلية عند غياب السياق. يُنصح كحد أدنى بجولة مراجعة واحدة يجرب فيها متحدث فعلي بتلك اللغة الشاشات. كذلك، الأهم قبل جودة الترجمة نفسها ضمان «عدم انهيار التخطيط عند طول النص بعد الترجمة»، عبر TableLayoutPanel وAutoSize مسبقاً.

هل يجب ترجمة السجلات ورسائل الأخطاء أيضاً؟

القاعدة الثابتة في العمل ترجمة الرسائل التي تظهر على شاشة المستخدم، وعدم ترجمة المحتوى المكتوب في ملفات السجلات أو سجل الأحداث (أي تثبيت لغة واحدة). السجلات يقرأها المطوّرون والقائمون على التشغيل لا المستخدمون، والسجلات متعددة اللغات تُفسد إمكانية البحث عند التحقيق. كذلك ثبّت تنسيق السجلات (التاريخ والأرقام) على CultureInfo.InvariantCulture. إن صممت التعامل مع CurrentCulture وCurrentUICulture منفصلين، تحقق هذا الفصل بين الاستخدامين طبيعياً.

هل ينبغي جعل التطبيق قادراً على تبديل اللغة بمعزل عن لغة عرض نظام التشغيل؟

عند النشر في فروع خارج اليابان، أو تطبيقات الأعمال التي يستخدمها موظفون ناطقون بلغات أجنبية داخل اليابان، تكون قيمة إعداد لغة خاص بالتطبيق عالية. الأسلوب الآمن نهجان: اتباع لغة عرض نظام التشغيل افتراضياً (القيمة الافتراضية لـ CurrentUICulture)، والكتابة فوقها فقط عند اختيار المستخدم الصريح لها من شاشة الإعدادات. وجعل تطبيق التبديل يتم «عند إعادة التشغيل التالية» كمواصفة هو الخيار الأكثر أماناً، إذ يبسّط التنفيذ وشرح طريقة الاستخدام.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.