DEV Community: Fuqiao Xue

Why Your Input Length Limit Is Wrong

Fuqiao Xue — Mon, 16 Mar 2026 04:35:02 +0000

You likely have a database field, a text input, or a textarea with a maxlength attribute. It is highly probable that the way your code calculates that length is incorrect for a global audience.

We are going to look at a practical, structural approach to text length, focusing on a concept called the grapheme cluster. By the end of this guide, you will understand exactly why standard string length properties fail, and how to fix them to respect international users.

When you ask a user for their name, and you limit it to 20 "characters", what do you actually mean?

If you use JavaScript and inspect the length property of a string, or measure string length in languages like Java or C#, you are usually measuring UTF-16 code units. If you are looking at a database like MySQL, you might be measuring bytes or Unicode code points.

None of these represent what a human user considers a "character".

Grapheme Cluster

In Unicode terminology, what a user perceives as a single visual unit of text is called a grapheme cluster. A grapheme cluster consists of a base character followed by zero or more combining characters that modify it.

Here are a few practical examples:

The letter é can be represented as a single code point (U+00E9), but it can also be represented as a base letter e (U+0065) followed by a combining acute accent ◌́ (U+0301). Visually, this is 1 grapheme cluster. To a naive string.length check, it appears as 2.

In the Devanagari script used for Hindi, the single visual unit क्ष्म consists of multiple code points, but represents just 1 grapheme cluster.

The "Woman Farmer" emoji 👩‍🌾 is constructed using the "Woman" emoji (U+1F469), a Zero Width Joiner (U+200D), and a "Sheaf of Rice" emoji (U+1F33E). That is 3 code points (and many more bytes!), but only 1 user-perceived character.

For more on how Unicode works under the hood, I recommend reviewing the W3C Character encodings essential concepts.

Why Your Input Limit is Breaking

When you strictly enforce an input length limit, you run a risk of truncating text in the middle of a grapheme cluster.

Imagine your database has a hard limit. A user pastes a string that looks like 10 characters to them, but occupies 12 code points. If your backend brutally slices the string at an arbitrary byte or code point boundary, you might sever a combining accent from its base letter, or split a family emoji back into floating disembodied heads.

This results in broken database records, corrupted user interfaces, and an inaccessible experience for users writing in Arabic, Indic, or Southeast Asian scripts, not to mention users who just want to use a flag emoji.

The Practical Solution

To build robust, reliable internationalized systems, you can measure lengths using grapheme clusters. Modern programming environments have built-in, standards-compliant tools to handle this.

In modern web development, the most efficient way to accurately count grapheme clusters is utilizing the Intl.Segmenter API provided by the ECMAScript Internationalization API.

// A string with an emoji, a combined diacritic, and standard Latin.
const userInput = "👩‍🌾éx";

// Code Units
console.log(userInput.length); // Output: 7

// The correct method: Using Intl.Segmenter
const segmenter = new Intl.Segmenter('en', { granularity: 'grapheme' });
const segments = segmenter.segment(userInput);

// Count the actual grapheme clusters
let graphemeCount = 0;
for (const segment of segments) {
  graphemeCount++;
}

console.log(graphemeCount); // Output: 3

By standardizing on Intl.Segmenter, you can ensure that your count of grapheme clusters is accurate.

We have a responsibility to build systems that work reliably regardless of the user's locale. For a broader understanding of how to implement global best practices in your web applications, please consult the W3C Internationalization techniques documentation.

The Ethical Imperative of Character Encoding

Fuqiao Xue — Thu, 29 Jan 2026 02:38:32 +0000

The World Wide Web was conceived as a space without borders. It's a medium where information could flow freely, where anyone could participate, and where all human expression would find digital form. This vision was articulated in the Web's founding documents and realized through decades of collaborative standards development. And there is a simple foundation: the ability to represent text.

Yet beneath this simplicity lies one of the most profound questions of our digital age: Who can be named on the Web? The answer to this question is determined by the architecture of character encoding. It is an ethical imperative that defines the boundaries of digital citizenship itself.

I. The Name as a Digital Gateway

A name is far more than an identifier. It is the key that unlocks participation in modern society. For example, tens of millions of people in China have names that contain rare characters. In addition, a significant number of place names and ancient texts have difficulties being digitalized due to rare characters contained within.

Consider what happens when a person's name cannot be represented in a digital system. In Huaiyuan county, Anhui province, more than 1,000 locals from a single village were forced to change their surnames because the character could not be typed into the computer system for registration. Their surname, Chi, written in traditional Chinese, cannot be found in the simplified Chinese font used by the system. As a result, these residents face difficulties in traveling, wealth management, and education, since a full name is required for most computer-based services.

This problem extends far beyond a single village. Government and public services in China are accelerating their digital transformation and moving operations online. However, many people's names and place names cannot be input, causing troubles in transactions such as opening bank accounts and purchasing transportation tickets. In another striking example, a village in Yunnan Province became famous when a local surname "Nia", meaning "a flying bird", could not be typed into computers. Many villagers with this family name were forced to register for ID cards using a similar character meaning "duck" instead.

When individuals cannot open bank accounts, purchase train tickets, register property, or obtain identification documents because their names exist outside the boundaries of supported character sets, a technical limitation has been transformed into a barrier to essential services.

II. The Architecture

As of Unicode 17.0, Unicode defines a total of 101,996 CJK Unified Ideograph characters. This represents an amazing achievement in technical standardization. The Ideographic Research Group (IRG) is very carefully cataloging, reviewing, and assessing CJK characters for inclusion into the standard. The only real limitation on the number of CJK characters in the standard is the ability of the IRG to process them.

Yet encoding a character in Unicode is only the first step in a longer journey. Several challenges remain.

The Encoding Gap

While Unicode has grown to encompass an impressive repertoire, gaps persist. There are a few people whose names contain characters not in Unicode.

The Implementation Gap

GB 18030 has registered more than 80,000 Chinese characters. However, most computers only support the input and display of about 30,000 commonly used characters.

A character may exist in the international standard, yet remain inaccessible to ordinary users for several reasons. Input methods may not support it, preventing users from typing the character in the first place. System fonts may not include glyphs for it, leaving only empty boxes or placeholder symbols on screen. Application software may fail to render or process it correctly, corrupting data as it moves through different programs. Furthermore, legacy systems often use incompatible encoding schemes, creating barriers when older infrastructure must interact with modern standards.

The Interoperability Gap

When different systems use different code points for the same character, whether through legacy Private Use Area assignments or historical encoding decisions, name comparison fails across systems. A person whose identity is encoded one way in the banking system and another way in the transportation system may be unable to prove they are who they say they are.

III. The Cascade of Consequences

The inability to represent one's name digitally initiates a cascade of consequences.

Without the ability to register their legal names, individuals cannot fully participate in the financial system. They cannot open accounts in their own names or engage in legitimate commerce. They are pushed to the margins of the digital economy.

Government services increasingly move online. Those whose names cannot be processed become administratively invisible.

Names connect individuals to their families, their communities, and their heritage. Every rare character is a part of the cultural heritage. They shouldn't be lost in the digital era. When people are forced to change their names to fit the constraints of computer systems, we witness a form of cultural erasure: the subordination of human identity to technical limitation.

The pressure to adopt "computer-compatible" names affects not only those living today but shapes naming practices for future generations. Traditional names, passed down through centuries, are abandoned. Regional variations and minority group naming conventions are homogenized. The rich diversity of onomastic tradition gives way to a narrower repertoire of "safe" choices.

IV. A Multi-Stakeholder Responsibility

Addressing this challenge requires coordinated action across multiple stakeholder groups. No single actor can solve this problem alone.

Standards Bodies

Newly proposed CJK unified ideographs are first submitted to the IRG through national bodies or liaison organizations, and are then assembled into a new "IRG Working Set" that goes through several rounds of detailed review and scrutiny before being approved for standardization as a new CJK Unified Ideographs extension block. Individuals who wish to propose the encoding of new CJK unified ideographs are encouraged to work with their respective country's national body.

The processes for proposing new characters must be accessible and efficient. The time between identifying an important unencoded character and its inclusion in the standard must be minimized.

Platform Providers and Software Developers

Platform providers must move beyond minimum compliance with standards to comprehensive implementation. This means:

Ensuring system fonts include glyphs for all encoded characters
Providing input methods that can access the full Unicode repertoire
Testing software with more characters, not merely common subsets
Supporting new character additions

Government Agencies

Governments must recognize character encoding as critical digital infrastructure and invest accordingly. This includes conducting comprehensive surveys to identify affected populations and establishing clear pathways for individuals to report encoding problems. Governments should also mandate comprehensive support for Unicode in both government systems and those of contractors.

Industry

Comprehensive font support is needed. Developers need to ensure that the chosen fonts include the necessary glyphs to accurately render Unicode characters. Proper font selection is crucial to maintain visual consistency and legibility in text.

Industry must treat character support not as a feature but as a fundamental accessibility requirement.

V. Building Awareness

Cases like the Yunnan village surname issue have drawn media coverage and online discussion. When people see that someone cannot get an ID card because their name uses a rare character, encoding stops being an abstract technical problem.

VI. Toward a Principled Framework

Every person should be able to represent their legal name accurately in any digital system that requires identification. This is not a matter of convenience but of fundamental dignity. The name is the primary marker of individual identity, and the inability to represent it constitutes a form of digital exclusion.

A name encoded in one system must be recognized and correctly processed in all other systems. The fragmentation of identity across incompatible encoding schemes imposes unacceptable burdens on individuals and undermines the integrity of identification systems.

Character encoding decisions should support, not undermine, the preservation of cultural heritage. Rare characters often carry particular cultural significance, like in family names passed down through generations or in place names that encode local history.

Rather than waiting for individuals to report that their names cannot be represented, responsible actors should proactively identify gaps and address them. This means conducting systematic surveys, engaging with affected communities, and establishing clear processes for adding needed characters.

VII. The Character of the Web

Character encoding is not merely a technical specification but a statement of values.

When we choose which characters to encode, implement, and support, we are choosing who can participate fully in the digital age. We are drawing the boundaries of the digital commons. We are determining whose names will be spoken by our machines and whose will be transformed, truncated, or erased.

Every name, every script, every writing tradition that has meaning for a community deserves a place in our digital infrastructure.

Unicode allows you to deal simply with almost all scripts and languages in use around the world. In this way Unicode simplifies the handling of content in multiple languages, whether within a single page or across one or more sites.

The technical capability exists. The standards framework is in place. What remains is the commitment from standards bodies, governments, industry, and civil society to complete the work of character support. This commitment honors not only those affected today but the generations to come, who deserve to inherit a digital world that can speak their names.

This is the Web we are called to build.

Mastering Web Internationalization

Fuqiao Xue — Tue, 04 Nov 2025 01:11:41 +0000

As developers striving for excellence, it is our responsibility to build web experiences that are not only functional but also accessible and inclusive for a global audience. Internationalization, often abbreviated as "i18n", is the practice of designing and developing applications that can be easily adapted to various languages and regions. This is not merely a matter of translation; it's a foundational aspect of quality development that, when addressed early, prevents costly future complications.

This article provides a structured, no-nonsense approach to the fundamentals of internationalization across the core technologies of the web: HTML, CSS, and JavaScript. Our objective is to equip you with the knowledge to build culturally considerate and robust web applications. For those who wish to delve deeper, the W3C Internationalization Activity provides a wealth of resources.

HTML Attributes

Correctly structuring your HTML is the first and most critical step in creating an internationalized website. Two global attributes are essential for this purpose: lang and dir.

The `lang` Attribute

The lang attribute specifies the primary language of an element's content. While it may seem like a minor detail, its impact is significant.

It assists search engines in understanding and correctly indexing your content for a global audience.

Screen readers use the lang attribute to pronounce text correctly, which is important for users with visual impairments.

It can influence the selection of appropriate typographic elements like quotation marks and hyphenation.

You can target specific languages in your CSS using the :lang() pseudo-class for language-specific styling adjustments.

Implementation:

It is best practice to set the primary language on the <html> element. This establishes a default for the entire document.

<!DOCTYPE html>
<html lang="en">
<head>
  <title>My Application</title>
</head>
<body>
  <p>This is an English paragraph.</p>
  <p lang="fr">Ceci est un paragraphe en français.</p>
</body>
</html>

In this example, the document's primary language is English (en). However, we have a paragraph in French (fr), and by setting the lang attribute on that <p> element, we provide a more accurate context to the browser and assistive technologies.

The `dir` Attribute

Languages like Arabic, Hebrew, and Urdu are written from right to left (RTL). The dir attribute is used to specify the text direction of an element's content. The three possible values are:

ltr: Left-to-right (default value).
rtl: Right-to-left.
auto: The browser determines the direction based on the content of the element.

Implementation:

Similar to the lang attribute, dir should be set on the <html> element to establish the base direction for the entire document. It should only be used on other elements when you need to override the base direction.

<!DOCTYPE html>
<html lang="ar" dir="rtl">
<head>
  <title>تطبيقي</title>
</head>
<body>
  <p>هذا النص من اليمين إلى اليسار.</p>
  <p dir="ltr">This text is left-to-right.</p>
</body>
</html>

In this case, the entire document is set to a right-to-left direction. A specific paragraph containing English text has its direction explicitly set to left-to-right. It is important to note that you should always declare the directionality using the dir attribute and not assume that a language declaration will also set the direction.

CSS Logical Properties

Historically, CSS properties were based on physical directions: top, bottom, left, and right. This approach creates significant challenges when building layouts that need to adapt to both LTR and RTL languages. For instance, margin-left in an LTR layout would need to become margin-right in an RTL context, often leading to separate, difficult-to-maintain stylesheets.

CSS Logical Properties and Values offer a more efficient and logical solution. They abstract directional concepts into block and inline axes, which are relative to the flow of text.

Block axis is the direction in which blocks of content are displayed (e.g., paragraphs). In languages like English, this is the vertical direction.

Inline axis is the direction of text within a line. For English, this is the horizontal direction.

This gives us flow-relative properties. For example:

Physical Property	Logical Property
`margin-left`	`margin-inline-start`
`margin-right`	`margin-inline-end`
`padding-left`	`padding-inline-start`
`padding-right`	`padding-inline-end`
`border-left`	`border-inline-start`
`border-right`	`border-inline-end`
`left`	`inset-inline-start`
`right`	`inset-inline-end`

Consider a simple card component with a small margin to its starting side.

The Physical Way:

.card {
  margin-left: 10px;
}

[dir="rtl"] .card {
  margin-left: 0;
  margin-right: 10px;
}

The Logical Way:

.card {
  margin-inline-start: 10px;
}

By using margin-inline-start, the margin is automatically applied to the left for LTR languages and to the right for RTL languages without any additional code. This approach is more maintainable and less error-prone.

JavaScript `Intl` API

While HTML and CSS provide the structure and styling for internationalization, JavaScript is crucial for handling dynamic data that requires locale-specific formatting. Internationalization is more than just translation; it encompasses formatting for dates, times, numbers, and currencies, which can vary significantly in different places.

The ECMAScript Internationalization API, accessed through the Intl object, provides a powerful, built-in solution for these challenges without the need for large, third-party libraries.

Problems Addressed by the `Intl` API

Date and Time Formatting: Displaying dates and times in a user's preferred format (e.g., MM/DD/YYYY in the US vs. DD/MM/YYYY in Germany).
Number Formatting: Correctly formatting numbers with appropriate separators for thousands and decimals (e.g., 1,234.56 in the US vs. 1.234,56 in Germany).
Currency Formatting: Displaying currency values with the correct symbol and placement.
Pluralization Rules: Handling singular and plural forms of words, which can be complex in different languages.
...

Examples

The Intl API works by creating formatter objects that are configured with a specific locale.

Formatting Dates:

const date = new Date();

const usDateFormatter = new Intl.DateTimeFormat('en-US');
console.log(usDateFormatter.format(date)); // e.g., "11/4/2025"

const germanDateFormatter = new Intl.DateTimeFormat('de-DE');
console.log(germanDateFormatter.format(date)); // e.g., "4.11.2025"

Formatting Numbers:

const number = 123456.789;

const usNumberFormatter = new Intl.NumberFormat('en-US');
console.log(usNumberFormatter.format(number)); // "123,456.789"

const germanNumberFormatter = new Intl.NumberFormat('de-DE');
console.log(germanNumberFormatter.format(number)); // "123.456,789"

Formatting Currency:

const amount = 1234.56;

const usCurrencyFormatter = new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' });
console.log(usCurrencyFormatter.format(amount)); // "$1,234.56"

const germanCurrencyFormatter = new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' });
console.log(germanCurrencyFormatter.format(amount)); // "1.234,56 €"

By leveraging the Intl object, you can deliver a more user-friendly experience that respects the cultural and linguistic nuances of your global audience.

Conclusion

Internationalization is a fundamental aspect of modern web development that should be integrated into your workflow from the very beginning. By systematically applying the correct attributes in HTML, utilizing logical properties in CSS, and leveraging the Intl API in JavaScript, you can build applications that are truly global. This structured approach not only enhances the user experience but also reflects a commitment to quality and inclusivity in the digital products we create.

The Core Principles of Web Internationalization

Fuqiao Xue — Tue, 02 Sep 2025 00:42:57 +0000

Introduction

Web internationalization (i18n) is the process of designing and developing websites and web applications that can be adapted to different languages, regions, and cultures without requiring engineering changes. As web developers, understanding the core principles of i18n is crucial in today's global digital landscape where users span diverse linguistic and cultural backgrounds.

This article explores some of the fundamental principles that form the foundation of effective web internationalization: Unicode and character encoding, text direction handling, and cultural neutrality.

Unicode and Character Encoding (UTF-8 is Not Enough)

While UTF-8 has become the de facto standard for web content encoding, simply declaring <meta charset="UTF-8"> is only the beginning of proper character handling.

Beyond Basic Encoding

UTF-8 supports the entire Unicode character set, but developers must consider:

Unicode Normalization: Different sequences of Unicode code points can represent the same visual character. For example, "é" can be represented as a single code point (U+00E9) or as "e" + combining acute accent (U+0065 U+0301).
Collation and Sorting: String comparison and sorting must account for locale-specific rules. The JavaScript Intl.Collator API provides locale-aware string comparison.
Case Conversion: Unicode case conversion is complex. Use String.prototype.toLocaleLowerCase() and toLocaleUpperCase() for locale-sensitive case changes.

Text Direction: LTR, RTL, and Bidi

Text direction is a critical aspect of internationalization that affects user experience and content readability.

Understanding Text Directions

LTR (Left-to-Right) is the default for most writing systems. RTL (Right-to-Left) is used for writing systems like Arabic and Hebrew. And bidirectional (bidi) means text that mixes LTR and RTL scripts within the same document.

Cultural Neutrality and Content Flexibility

Cultural neutrality means avoiding assumptions about user preferences and providing content that adapts to different cultural contexts.

Avoiding Cultural Assumptions

Here are some aspects related to culture:

Date and Time Formats: Never hardcode formats like "MM/DD/YYYY". Use Intl.DateTimeFormat for locale-appropriate formatting.
Number Formatting: Currency, decimal separators, and grouping vary by locale. Use Intl.NumberFormat.
Measurement Units: Provide conversions or allow user preference selection.
Color Symbolism: Colors can have different cultural meanings (e.g., red signifies danger in Western cultures but luck in Chinese culture).

Conclusion

Effective web internationalization goes beyond mere translation. By embracing Unicode properly, handling text direction correctly, maintaining cultural neutrality, and adopting a locale-aware development mindset, web developers can create applications that truly serve a global audience.

Remember, internationalization is not an afterthought, but a fundamental aspect of modern web development. As the web continues to connect people across cultures and languages, mastering these core principles will become increasingly essential for delivering inclusive, accessible, and user-friendly web experiences.

Localization vs. Internationalization

Fuqiao Xue — Tue, 03 Jun 2025 03:17:27 +0000

When building digital products for a global audience, two concepts often come up—internationalization (i18n) and localization (L10n). While these terms are frequently used together, they describe different (but complementary) processes. Understanding the distinction is essential for developers, designers, product managers, and anyone building for the web. For more information, visit the W3C Internationalization site.

Let’s break it down: what they mean, why the difference matters, and how you can implement both effectively in your projects.

What Is Internationalization?

Internationalization (i18n) is the process of designing and developing software so it can be adapted to various languages and regions without requiring engineering changes. It's about building flexibility into the foundation of your codebase and UI.

Examples of internationalization:

Using Unicode (UTF-8) to support a wide range of scripts
Structuring date and time formats using Intl.DateTimeFormat
Supporting both left-to-right and right-to-left layouts
Designing flexible UI layouts that can accommodate text expansion

What Is Localization?

Localization (L10n) is the process of adapting your product to a specific locale or market. It involves translating content and modifying visual, textual, and maybe functional elements to meet the expectations of a target audience.

Localization is what users actually see—it’s the translation and cultural adjustments tailored to a specific region.

Examples of localization:

Translating UI text, help documentation, and alt text into French
Changing date formats to YYYY-MM-DD in China
Adjusting color schemes, imagery, or tone to suit cultural norms
Replacing metaphors or idioms with locally relevant equivalents

DEV Community: Fuqiao Xue

Why Your Input Length Limit Is Wrong

Grapheme Cluster

Why Your Input Limit is Breaking

The Practical Solution

The Ethical Imperative of Character Encoding

I. The Name as a Digital Gateway

II. The Architecture

The Encoding Gap

The Implementation Gap

The Interoperability Gap

III. The Cascade of Consequences

IV. A Multi-Stakeholder Responsibility

Standards Bodies

Platform Providers and Software Developers

Government Agencies

Industry

V. Building Awareness

VI. Toward a Principled Framework

VII. The Character of the Web

Mastering Web Internationalization

HTML Attributes

The lang Attribute

The dir Attribute

CSS Logical Properties

JavaScript Intl API

Problems Addressed by the Intl API

Examples

Conclusion

The Core Principles of Web Internationalization

Introduction

Unicode and Character Encoding (UTF-8 is Not Enough)

Beyond Basic Encoding

Text Direction: LTR, RTL, and Bidi

Understanding Text Directions

Cultural Neutrality and Content Flexibility

Avoiding Cultural Assumptions

Conclusion

Localization vs. Internationalization

What Is Internationalization?

Examples of internationalization:

What Is Localization?

Examples of localization:

The `lang` Attribute

The `dir` Attribute

JavaScript `Intl` API

Problems Addressed by the `Intl` API