نظرات مطالب
خلاصه اشتراک‌های روز چهار شنبه 1390/06/30
سلام
چند تا از این لینک ها رو که خواستم باز کنم Page Not Found می دادند که مربوط به وبلاگ های  msdn هستند مثلا Kinect SDK For PC - VB Samples available
لطفا شما هم یک بررسی کنید
نظرات مطالب
NHibernate 3 Beginners Guide
سورس این نوع پروژه‌ها برای کسانی که EF یا NH رو نوشتن خوبه. به اون‌ها ایده می‌ده؛ ولی به درد من و شما نمی‌خوره و وقت تلف کردن است. از هر چیزی که GUI داره برای طراحی دوری کنید! ORM ها زمانیکه قسمت عمده کار را از شما مخفی می‌کنند شاید به ظاهر برای یک تازه کار جذاب باشند ولی هر چقدر که جلوتر می‌رن محبور می‌شن به پشت صحنه بیشتر رجوع کنند. NH از روز اول همون پشت صحنه رو نشون می‌ده. صادق هست. ضمنا برای انتخاب هر کتابخانه‌ی نسبتا پایه‌ای باید به این مسایل دقت کنید:
- چه تعداد کتاب چاپ شده در این مورد هست؟
- چه تعداد انجمن برای رفع اشکال آن وجود دارد؟
- چه تعداد بلاگ و سایت در این زمینه مطلب و مقاله منتشر می‌کنند؟
- آخرین تاریخ به روز رسانی آن کی بوده؟
benchmark مهم نیست. گیرم این یکی دو ثانیه زودتر از اون یکی جواب بده. چه اهمیتی داره؟ مهم این است که چند نفر با این کتابخانه کار می‌کنند، چه تعداد منبع دارد و آیا می‌شود در روزهای سخت دنبال پاسخگو گشت؟
NH یک خوبی دیگر هم دارد. در سایت‌های دات نتی مطلب پیدا نکردید، معادل یک به یک جاوا هم دارد.
EF هم داره خوب میشه. این نگارش 4.1 آن خیلی شبیه به Fluent NHibernate شده.
مطالب
مدیریت مرکزی شماره نگارش‌های بسته‌های NuGet در پروژه‌های NET Core.
عموما برنامه‌های بزرگ NET.، به چندین زیر پروژه شکسته می‌شوند تا مدیریت آن‌ها ساده‌تر شود. مهم‌ترین مشکلی که در این حالت پس از مدتی بروز می‌کند، هماهنگ نگه داشتن شماره نگارش‌های ارجاعات NuGet این پروژه‌ها است و همچنین به روز رسانی مکرر و هر باره‌ی تمام این فایل‌های csproj. به همین جهت ایده‌ی مدیریت مرکزی شماره نگارش‌های ارجاعات پروژه‌های NuGet قرار است به نگارش بعدی آن اضافه شود که البته هم اکنون نیز قسمتی از آن در NET Core SDK 3.1.300. به بعد، قابل استفاده‌است که جزئیات آن‌را در ادامه مرور می‌کنیم.


ایجاد فایل جدید Directory.Packages.props

زمانیکه قرار است شماره نگارش‌های بسته‌های NuGet مختلف مورد استفاده‌ی در برنامه، به صورت مرکزی مدیریت شوند، نیاز به یک مخزن ثبت آن‌ها نیز می‌باشد. به همین جهت یک فایل جدید را به نام Directory.Packages.props در کنار فایل sln پروژه‌ی خود ایجاد کنید (در ریشه‌ی اصلی پروژه)؛ با این محتوای فرضی:
<Project>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" />
    <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" />
  </ItemGroup>
</Project>
برای تشکیل این فایل، فایل‌های csproj مختلف موجود در solution جاری را یافته و سپس PackageReference‌های آن‌ها را به فایل props فوق کپی کنید؛ با یک تفاوت مهم: بجای PackageReference اینبار از نام PackageVersion استفاده می‌شود.


تغییرات مورد نیاز در فایل‌های پروژه‌های موجود

در ادامه مجددا به تمام فایل‌های csproj خود مراجعه کرده و ویژگی Version را از آن‌ها حذف کنید؛ مانند:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Localization.Abstractions" />
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" />
  </ItemGroup>
</Project>
 از این پس دیگر هیچکدام از فایل‌های پروژه‌ی شما نباید به همراه قید صریح شماره نگارش بسته‌های مورد استفاده باشند؛ در غیر اینصورت در حین Build پروژه، خطای زیر را دریافت خواهید کرد:
error NU1008: Projects that use central package version management should not define the version on the PackageReference items

همچنین اگر دقت کرده باشید، ویژگی جدید ManagePackageVersionsCentrally نیز به این فایل پروژه و سایر فایل‌های پروژه نیز باید اضافه شود. حالت پیش‌فرض آن false است.

یک نکته: می‌توان ویژگی ManagePackageVersionsCentrally را نیز به صورت سراسری به فایل Directory.Packages.props اضافه کرد تا به صورت خودکار به تمام فایل‌های csproj موجود، اعمال شود:
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" />
    <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" />
  </ItemGroup>
</Project>


نحوه‌ی افزودن بسته‌های جدید

قابلیتی که تا اینجا معرفی شد، در NET Core SDK 3.1.300. به بعد قابل دسترسی و استفاده‌است (و پس از این تغییرات، برنامه بدون مشکل کامپایل می‌شود)؛ اما هنوز NET Core CLI. برای افزودن خودکار بسته‌های جدید NuGet به این سیستم، به روز رسانی نشده‌است. یعنی فعلا اگر خواستید بسته‌ی جدیدی را اضافه کنید باید ابتدا به صورت دستی PackageVersion آن‌را در فایل Directory.Packages.props ثبت کنید و سپس PackageReference بدون شماره‌ی نگارش را نیز به پروژه‌ی مدنظر خود به صورت دستی اضافه کنید.



برای مطالعه بیشتر
مستندات رسمی آن
وضعیت پیاده سازی آن
مطالب
آشنایی با CLR: قسمت یازدهم
انتشار نوع‌ها  (Types) به یک ماژول
در این قسمت به نحوه‌ی تبدیل سورس به یک فایل قابل انتشار می‌پردازیم. کد زیر را به عنوان مثال در نظر بگیرید:
public sealed class Program {
  public static void Main() {
    System.Console.WriteLine("Hi");
  }
}
این کد یک ارجاع به نام کنسول دارد که این ارجاع، داخل فایلی به نام mscorlib.dll قرار دارد. پس برنامه‌ی ما نوعی را دارد، که آن نوع توسط شرکت دیگری پیاده سازی شده است. برای ساخت برنامه‌ی کد بالا، کدها را داخل فایلی با نام program.cs قرار داده و با دستور زیر در خط فرمان آن را کامپایل می‌کنیم:
csc.exe /out:Program.exe /t:exe /r:MSCorLib.dll Program.cs
کد بالا با سوئیچ اول می‌گوید که فایلی را با نام program.exe درست کن و با سوئیچ دوم می‌گوید که این برنامه از نوع کنسول هست.
موقعیکه کامپایلر فایل سورس را مورد بررسی قرار می‌دهد، متوجه متد writerline می‌گردد؛ ولی از آنجاکه این نوع توسط شما ایجاد نشده است و یک نوع خارجی است، شما باید یک مجموعه از ارجاعات را به کمپایلر داده تا آن نوع را در آن‌ها بیابد. ارائه این ارجاعات به کامپایلر توسط سوئیچ r/ که در خط بالا استفاده شده است، صورت می‌گیرد.


mscorlib یک فایل سورس است که شامل همه‌ی نوع‌ها، از قبیل int,string,byte و خیلی از نوع‌های دیگر می‌شود. از آنجائیکه استفاده‌ی از این نوع‌ها به طور مکرر توسط برنامه نویس‌ها صورت می‌گیرد، کمپایلر به طور خودکار این کتابخانه را به لیست ارجاعات اضافه می‌کند. به بیان دیگر خط بالا به شکل زیر هم قابل اجراست:
csc.exe /out:Program.exe /t:exe Program.cs

به علاوه از آنجایی که بقیه‌ی سوئیچ‌ها هم مقدار پیش فرضی را دارند، خط زیر هم معادل خطوط بالاست:
csc.exe Program.cs

اگر به هر دلیلی دوست ندارید که سمت mscorlib ارجاعی صورت بگیرید، می‌توانید از دستور زیر استفاده کنید:
/nostdlib

مایکروسافت موقعی از این سوئیچ بالا استفاده کرده است که خواسته است خود mscorlib را بسازد. با اضافه کردن این سوئیچ، کد مثال که حاوی شیء یا نوع کنسول است به خطا برخواهد خورد چون تعریف آن در mscorlib صورت گرفته و شما با سوئیچ بالا دسترسی به آن را ممنوع اعلام کرد‌ه‌اید و از آنجاکه این نوع تعریف نشده، برنامه ازکامپایل بازخواهد ماند.
csc.exe /out:Program.exe /t:exe /nostdlib Program.cs

بیایید نگاه دقیقتری به فایل program.exe ساخته شده بیندازیم؛ دقیقا این فایل چه نوع فایلی است؟ برای بسیاری از مبتدیان، این یک فایل اجرایی است که در هر دو ماشین 32 و 64 بیتی قابل اجراست. ویندوز از سه نوع برنامه پشتیبانی می‌کند: CUI یا برنامه‌های تحت کنسول، برنامه‌هایی با رابط گرافیکی GUI و برنامه‌های مخصوص windows store که سوئیچ‌های آن به شرح زیر است:
//CUI
/t:exe

//GUI
/t:winexe

//Winsows store App
/t:appcontainerexe

قبل از اینکه بحث را در مورد سوئیچ‌ها به پایان برسانیم، اجازه دهید در مورد فایل‌های پاسخگو یا response file صحبت کنیم. یک فایل پاسخگو، فایلی است که شامل مجموعه‌ای از سوئیچ‌های خط فرمان می‌شود. موقعی‌که csc.exe اجرا می‌شود، به فایل پاسخگویی که شما به آن معرفی کرده‌اید مراجعه کرده و فرمان را با سوئیچ‌های داخل آن اجرا می‌کند. معرفی یک فایل پاسخگو به کامپایلر توسط علامت @ و سپس نام فایل صورت می‌گیرد و در این فایل هر خط، شامل یک سوئیچ است. مثلا فایل پاسخگوی response.rsp شامل سوئیچ‌های زیر است:
/out:MyProject.exe
/target:winexe

و برای در نظر گرفتن این سوئیچ‌ها فایل پاسخگو را به کامپایلر معرفی می‌کنیم:
csc.exe @MyProject.rsp CodeFile1.cs CodeFile2.cs

این فایل خیلی کار شما را راحت می‌کند و نمی‌گذارد در هر بار کامپایل، مرتب سوئیچ‌های آن را وارد کنید و کیفیت کار را بالا می‌برد. همچنین می‌توانید چندین فایل پاسخگو داشته باشید و هر کدام شامل سوئیچ‌های مختلفی تا اگر خواستید تنظیمات کامپایل را تغییر دهید، به راحتی تنها نام فایل پاسخگو را تغییر دهید. همچنین کامپایلر سی شارپ از چندین فایل پاسخگو هم پشتیبانی می‌کند و می‌توانید هر تعداد فایل پاسخگویی را به آن معرفی کنید. در صورتیکه فایل را با نام csc.rsp نامگذاری کرده باشید، نیازی به معرفی آن نیست چرا که کامپایلر در صورت وجود، آن را به طور خودکار خواهد خواند و به این فایل global response file یا فایل پاسخگوی عمومی گویند.
در صورتیکه چندین فایل پاسخگو که به آن فایل‌های محلی local می‌گویند، معرفی کنید که دستورات آن‌ها(سوئیچ) با دستورات داخل csc.rsp مقدار متفاوتی داشته باشند، فایل‌های محلی الویت بالاتری نسبت به فایل global داشته و تنظمیات آن‌ها روی فایل global رونوشت می‌گردند.

موقعی‌که شما دات نت فریمورک را نصب می‌کنید، فایل csc.rsp را با تنظیمات پیش فرض در مسیر زیر نصب می‌کند:
%SystemRoot%\
Microsoft.NET\Framework(64)\vX.X.X

حروف x نمایانگر نسخه‌ی دات نت فریمورکی هست که شما نصب کرده‌اید. آخرین ورژن از این فایل در زمان نگارش کتاب، شامل سوئیچ‌های زیر بوده است.
# This file contains command­line options that the C#
# command line compiler (CSC) will process as part
# of every compilation, unless the "/noconfig" option
# is specified.
# Reference the common Framework libraries
/r:Accessibility.dll
/r:Microsoft.CSharp.dll
/r:System.Configuration.dll
/r:System.Configuration.Install.dll
/r:System.Core.dll
/r:System.Data.dll
/r:System.Data.DataSetExtensions.dll
/r:System.Data.Linq.dll
/r:System.Data.OracleClient.dll
/r:System.Deployment.dll
/r:System.Design.dll
/r:System.DirectoryServices.dll
/r:System.dll
/r:System.Drawing.Design.dll
/r:System.Drawing.dll
/r:System.EnterpriseServices.dll
/r:System.Management.dll
/r:System.Messaging.dll
/r:System.Runtime.Remoting.dll
/r:System.Runtime.Serialization.dll
/r:System.Runtime.Serialization.Formatters.Soap.dll
/r:System.Security.dll
/r:System.ServiceModel.dll
/r:System.ServiceModel.Web.dll
/r:System.ServiceProcess.dll
/r:System.Transactions.dll
/r:System.Web.dll
/r:System.Web.Extensions.Design.dll
/r:System.Web.Extensions.dll
/r:System.Web.Mobile.dll
/r:System.Web.RegularExpressions.dll
/r:System.Web.Services.dll
/r:System.Windows.Forms.Dll
/r:System.Workflow.Activities.dll
/r:System.Workflow.ComponentModel.dll
/r:System.Workflow.Runtime.dll
/r:System.Xml.dll
/r:System.Xml.Linq.dll

این فایل حاوی بسیاری از ارجاعات اسمبلی‌هایی است که بیشتر توسط توسعه دهندگان مورد استفاده قرار می‌گیرد و در صورتیکه برنامه‌ی شما به این اسمبلی‌ها محدود می‌گردد، لازم نیست که این اسمبلی‌ها را به کامپایلر معرفی کنید.
البته ارجاع کردن به این اسمبلی‌ها تا حد کمی باعث کند شدن صورت کامپایل می‌شوند؛ ولی تاثیری بر فایل نهایی و نحوه‌ی اجرای آن نمی‌گذارند.

نکته: در صورتی که قصد ارجاعی را دارید، می‌توانید آدرس مستقیم اسمبلی را هم ذکر کنید. ولی اگر تنها به نام اسمبلی اکتفا کنید، مسیرهای زیر جهت یافتن اسمبلی بررسی خواهند شد:
  • دایرکتوری برنامه
  • دایرکتوری که شامل فایل csc.exe می‌شود. که خود فایل mscorlib از همانجا خوانده می‌شود و مسیر آن شبیه مسیر زیر است:
%SystemRoot%\Microsoft.NET\Framework\v4.0.#####

  • هر دایرکتوری که توسط سوئیچ lib/ مشخص شده باشد.
  • هر دایرکتوری که توسط متغیر محلی lib مشخص شده باشد.
استفاده از سوئیچ noconfig/ هم باعث می‌شود که فایل‌های پاسخگوی از هر نوعی، چه عمومی و چه محلی، مورد استفاده قرار نگیرند. همچنین شما مجاز هستید که فایل csc.rsp را هم تغییر دهید؛ ولی این نکته را فراموش نکنید، در صورتی که برنامه‌ی شما به سیستمی دیگر منتقل شود، تنظیمات این فایل در آنجا متفاوت خواهد بود و بهتر هست یک فایل محلی را که همراه خودش هست استفاده کنید.
در قسمت بعدی نگاه دیگری بر متادیتا خواهیم داشت.
مطالب
SFDown

چند روز قبل جهت دریافت فایل‌های تنظیم سطح دوم کش NHibernate به سایت سورس فورج مراجعه کردم و ... آه از نهادم برخاست! نه از این جهت که این سایت مدت مدیدی است ما رو تحریم کرده، به این دلیل که سورس فورج حتی با IP غیر ایرانی تونسته بود موقعیت من رو شناسایی کنه. شبیه به همین مورد مدتی است توسط گوگل نیز بکارگرفته میشه. به نظر میرسه این وسط جایی نشتی وجود داره. برای مثال در فایرفاکس امکان گزارش Geo Location به صورت پیش فرض فعال است. هر چند در مستندات آن صراحتا عنوان شده که ... خیر ... ما این اطلاعات را بدون تائید شما بروز نمی‌دهیم؛ ولی سؤال اینجا است که چطور تونستند از روی IP غیرایرانی، موقعیت من رو تشخیص دهند؟!
غیر فعال کردن این مورد هم ساده است. مطابق تصویر زیر عمل کنید:



به عبارتی در نوار آدرس فایرفاکس عبارت about:config را تایپ کرده، سپس عبارت geo.enabled را یافته و غیرفعال کنید. اکنون نیاز است یکبار مرورگر را بسته و باز کنید.
و ... IP ایی که سوخت ... تا یکی دو هفته عمل نخواهند کرد و بعد از لیست سیاه پاک خواهد شد.

برای رفع این نقیصه و ساده‌تر کردن دریافت فایل‌ها از سورج فورج، برنامه‌ی کوچکی را تهیه کرده‌ام که با گرفتن آدرس یک پروژه سورس فورج، لینک مستقیم قابل دریافت فایل‌های آن‌را در اختیار شما قرار می‌دهد. این برنامه بر اساس Mirror های سورس فورج عمل می‌کند و به صورت خودکار تمام آن‌ها را بررسی کرده و مورد قابل استفاده را گزارش خواهد داد. یا می‌توانید توسط خود برنامه فایل نهایی را دریافت کنید یا امکان کپی کردن یا ذخیره کردن لینک‌های مستقیم نهایی یافت شده، در برنامه پیش بینی شده است (جهت دریافت توسط برنامه download manager مورد علاقه شما).




مطالب
مدیریت اسپم‌ها در SignalR
سناریویی را در نظر بگیرید که در آن یک برنامه‌ی چت را با استفاده از SignalR نوشته‌اید و قصد دارید از آن در یک سایت شلوغ استفاده کنید. در حالت عادی برنامه به خوبی کار می‌کند؛ تا زمانیکه کسی شروع به ارسال Spam در سیستم چت شما نکرده باشد. برای کنترل ارسال spam، اولین راهی که به ذهن می‌رسد این است که سمت کلاینت کلید ارسال پیغام را چند ثانیه غیر فعال کنیم تا کاربران نتوانند در عرض به طور مثال 3 ثانیه، تعداد زیادی پیام را ارسال کنند. برای کاربران معمولی وب سایت ما این راه حل جواب می‌دهد و مشکلی نیست. ولی اگر کاربر وب‌سایت آشنایی مختصری با JavaScript و نحوه‌ی اتصال به signalR داشته باشد چطور؟ خیلی ساده می‌تواند در کنسول browser خود یک لوپ نوشته و شروع به ارسال spam به برنامه‌ی چت ما کند. اینجاست که مجبوریم به علاوه‌ی کنترل سمت کلاینت، سمت سرور هم زمان ارسال پیام‌ها را کنترل کنیم که در ادامه به یکی از روش‌های انجام این کار می‌پردازیم.

کد اولیه‌ی هاب چت برنامه:
<HubName("chat")>
Public Class ChatHub
    Inherits Hub
    Public Sub sendMessage(msg As String) 
         Clients.All.getMessage(msg) 'Call getMessage function client side
    End Sub
End Class
برای شروع کار ابتدا نیاز به کلاسی داریم که اطلاعات فعالیت‌های کانکشن‌ها را برای ما نگه‌داری کند:
Public Class ActivityInfo
    Sub New(connectionId As String)
        Me.ConnectionID = connectionId
        Me.Time = Now
    End Sub
    Public Property ConnectionID As String
    Public Property Time As DateTime
End Class
سپس برای اینکه بتوانیم تمامی درخواست‌های ارسالی از سمت کلاینت‌ها را مدیریت کنیم، به یک کلاس از نوع HubPipelineModule احتیاج داریم که ما در اینجا با استفاده از کلاس SpamDetectionPiplelineModule که از HubPipelineModule مشتق شده، این کار را انجام می‌دهیم.
Public Class SpamDetectionPiplelineModule
    Inherits HubPipelineModule
    Public Property SpamDetection As New HashSet(Of ActivityInfo)
    Private _SpamDetectionLock As New Object
    Public Function IsSpam(ConnectionId As String) As Boolean
        SyncLock _SpamDetectionLock
            'Remove all old info before 3 seconds ago
            SpamDetection.RemoveWhere(Function(q) q.Time < Now.AddSeconds(-3))

            SpamDetection.Add(New ActivityInfo(ConnectionId))

            'Check activities from 3 seconds ago
            If SpamDetection.Where(Function(q) q.ConnectionID = ConnectionId).Count > 2 Then
                Return True
            Else
                Return False
            End If
        End SyncLock
    End Function
    Protected Overrides Function OnBeforeIncoming(context As IHubIncomingInvokerContext) As Boolean
        If IsSpam(context.Hub.Context.ConnectionId) Then
            Return False
        End If
        Return MyBase.OnBeforeIncoming(context)
    End Function
End Class
در کدهای بالا ابتدا یک HashSet را جهت نگه داشتن فعالیت کاربران ایجاد کردیم که بعد از هر درخواستی که به سمت سرور ارسال می‌شود، به‌روز خواهد شد. متد OnBeforeIncoming قبل از اینکه درخواست کاربر به Hub برنامه برسد، اجرا می‌شود که میتوانیم با استفاده از آن، فعالیت‌های کانکشن کاربر را در طی چند ثانیه‌ی اخیر کنترل کنیم که برای مثال چه تعدادی درخواست را در طی 3 ثانیه‌ی قبل ارسال کرده است. اگر تعداد درخواست‌های ارسالی در طی 3 ثانیه‌ی قبل، بیشتر از تعداد مورد نظر ما بود، با بازگشت دادن False، از اجرای درخواست آن جلوگیری می‌کنیم. (در اینجا ما کاربران را به ارسال 2 پیام در طی هر 3 ثانیه، محدود کرده‌ایم).
حال برای استفاده‌ی از PipelineModule سفارشی خودمان، باید آن را قبل از مپ کردن SignaR، در StartUp برنامه اضافه کنیم:
Public Class Startup
    Public Sub Configuration(app As IAppBuilder)
        GlobalHost.HubPipeline.AddModule(New SpamDetectionPiplelineModule)
        app.MapSignalR
    End Sub
End Class
مطالب
بومی‌سازی چیست؟

بومی‌سازی فرآیندی است که طی آن یک محصول برای کار در یک محیط خاص آماده می‌شود. این فرآیند شامل مراحل متفاوتی است و در آن باید موارد بسیاری را در نظر داشت. در طی چند مطلب به چگونگی این کار خواهیم پرداخت و در این مطلب صرفا به معرفی مواردی که باید در نظر داشت خواهیم پرداخت.

بومی‌سازی محصول الزاما به این معنی نیست که یک محصول خارجی را طوری تغییر دهیم که بشود از آن در داخل کشور استفاده کرد. بومی‌سازی صرفا تغییر نوشته‌های یک محصول نیست که با ترجمه آن، برنامه بومی شده باشد. بومی‌سازی یک پروسه زمان‌بر و پیچیده است و بطرز شگفت‌آوری با جهانی‌سازی مرتبط است.

در واقع ما زمانی یک برنامه را بومی می‌کنیم که بخواهیم در کشورها یا بوم‌های مختلف از آن استفاده کنیم. از آنجا که این تغییرات بعضا از هم تاثیر پذیر هستند کاربردپذیری هر برنامه را تغییر خواهند داد. برای مثال در نظر بگیرید یک برنامه را که روی تولید نام کاربری به زبان‌های مختلف محدودیتی ایجاد نکرده و قرار است در چندین کشور مختلف (وب) از آن استفاده شود. حروف مشابه ولی در باطن متفاوت در بوم‌های مختلف چه بلایی سر برنامه خواهند آورد؟ فرض کنید شبکه اجتماعی توئیتر شما را در تولید کلمه کاربری با زبان فارسی و عربی آزاد بگذارد. وقتی به @علی یک پیغام می‌فرستید، چه کسی این پیغام را تحویل خواهد گرفت؟ صاحب این اکانت در عربستان یا ایران؟


با اینکه بومی‌سازی لزوما ارتباط چندانی با کاربردپذیری ندارد اما در کاربردپذیر کردن برنامه و استانداردهای برنامه بطرز چشمگیری تاثیرگذار است. موارد مختلفی را باید در هنگام تولید یک برنامه چندزبانه در نظر داشت از جمله:
  • از این برنامه در چه کشورهایی استفاده خواهد شد؟
  • چه نوع تقویم‌هایی را باید پشتیبانی نماید؟
  • نحوه افزودن زبان جدید به برنامه چگونه خواهد بود؟
  • تکمیل فیلدهای حساس مانند نام کاربری به چه زبانی مجاز است؟
  • تولید صفحات برنامه در جهات مختلف به چه صورت خواهد بود؟
  • تجربه کاربری مناسب برای کاربری که راست به چپ می‌نویسد و کاربرزی که چپ به راست می‌نویسد چگونه است؟
  • شرکت‌های بزرگ چطور با این مشکلات روبرو می‌شوند؟
  • ذخیره داده‌ها در پایگاه داده باید به چه صورتی و با چه زبان مرجعی صورت پذیرد؟
  • تبدیل و تغییر داده‌ها چقدر لازم است؟

بزودی با هر یک از این موارد بیشتر آشنا خواهیم شد و هر مورد را بصورت جداگانه بررسی خواهیم کرد.


تعاریف :

بوم : Local
بومی : Localized
بومی‌سازی : Localization
جهانی‌سازی : Globalization
کاربردپذیر : Usability