The State of Gemini Nano Multilingual Support: When Will Hebrew and Arabic Be Available?

Introduction: The Language Divide in On-Device AI

With the launch of Google's Pixel 10 series, the on-device Gemini Nano model has once again become a focal point for the tech community. Recently, a user who had just gotten a Pixel 10 raised a rather representative question on Reddit: When will Gemini Nano support more languages like Hebrew and Arabic?

This seemingly simple question actually reveals a long-overlooked pain point in the development of on-device AI—the uneven coverage of languages. Statistically, there are roughly 7,000 languages worldwide, yet mainstream on-device AI models typically support fewer than 50 languages, heavily concentrated on major languages such as English, Chinese, and Japanese. Researchers refer to this phenomenon as the "AI Language Gap." For the billions of users worldwide who speak non-English languages, the accessibility of AI capabilities often depends on whether their native language is prioritized—and users whose native tongue is a minority language are often also the groups most reliant on offline functionality, creating a double layer of digital inequality.

What Is Gemini Nano?

A Lightweight Model Designed for On-Device Use

Gemini Nano is the smallest and most lightweight version in Google's Gemini family, designed specifically to run locally on mobile devices. Unlike Gemini Pro or Ultra, which require connecting to cloud computing power, Nano runs directly on the phone's Neural Processing Unit (NPU) and exposes its capabilities through the Android AICore system service.

The NPU is a specialized chip module designed to accelerate neural network inference operations, distinct from the general-purpose CPU and the graphics-rendering GPU. Modern flagship phone SoCs (such as Qualcomm's Snapdragon 8 series, MediaTek's Dimensity 9 series, and Google's in-house Tensor series) all integrate a dedicated NPU capable of performing core AI operations like matrix multiplication at far lower power consumption than the CPU. The NPU in Google's Tensor G4 chip (used in the Pixel 9/10 series) was designed from the outset with the inference efficiency of Gemini Nano as a key optimization target.

Android AICore is a system-level AI runtime framework that Google formally introduced in Android 14. Its core design philosophy is to manage large AI models as operating-system-level shared resources rather than having each application bundle them separately. This architecture effectively solves the problem of storage redundancy—if every app calling Gemini Nano bundled its own copy of the model, it would cause gigabytes of duplicated storage usage. AICore distributes model weights via Google Play system updates (APEX modules), supports silent background model updates, and provides standardized Java/Kotlin APIs for developers to call. Notably, AICore is currently fully open only on Pixel devices, and third-party OEMs vary widely in their level of integration—one of the key reasons for the fragmentation of the Gemini Nano ecosystem. Developers don't need to bundle the model themselves; they can invoke Nano's capabilities through a standard interface.

This on-device deployment brings three core advantages:

Privacy protection: Data doesn't need to be uploaded to the cloud, keeping sensitive information local
Low latency: No network round-trips, resulting in more immediate responses
Offline availability: Works normally even without a network connection

Currently, Gemini Nano already powers several features on Pixel devices, including call summaries, recording transcription and summarization, Gboard smart replies, and Magic Compose.

The Multilingual Bottleneck Caused by Model Size

However, it is precisely this "small and elegant" design that constitutes the fundamental bottleneck for multilingual support. To run within a phone's limited memory and computing power, the Nano model must drastically compress its parameter scale. Mainstream compression techniques in the industry include: Quantization—reducing model weights from 32-bit floating point to 8-bit integer or even 4-bit representations, greatly reducing storage and computation requirements; Knowledge Distillation—using the outputs of a large model (the "teacher") to train a small model (the "student"), enabling the small model to inherit the behavior patterns of the large one; and Pruning—removing neural network connections that contribute little to the output. While these compression methods are effective, each step incurs a certain loss of capability, and the vocabulary expansion and language-specific parameters required for multilingual support are precisely the hardest parts to preserve during compression.

This means Nano cannot cover hundreds of languages like cloud-based large models can; it must make trade-offs during training. Every additional language that requires full support demands extra training data, model tuning, and quality validation—a considerably high marginal cost for a model built on the premise of being size-constrained.

Why Are Hebrew and Arabic Support Lagging Behind?

The Technical Complexity of the Languages Themselves

Both Hebrew and Arabic belong to the right-to-left (RTL) writing system, which places higher demands on the system in terms of text rendering, cursor handling, and mixed-direction layout (such as embedding English or numbers). The engineering complexity of RTL languages goes far beyond a visual mirror flip—the Unicode standard defines the Unicode Bidirectional Algorithm (UBA) to handle the conversion between logical order and visual order when RTL and LTR text are mixed.

Specifically, the UBA (defined in Unicode Standard Annex #9) assigns each Unicode character a "bidirectional type" (such as Strong Left-to-Right, Strong Right-to-Left, European Number, etc.), and then, through paragraph-level determination, explicit directional marks (such as U+200F RIGHT-TO-LEFT MARK), and bracket-pairing rules, ultimately converts the logical storage order into the visual display order on screen. For example, when an Arabic sentence contains embedded numbers and English brand names, the display position of each character requires recursive computation involving dozens of rules to determine, making the engineering implementation extremely complex.

At the AI model level, the challenges are equally severe. Arabic is a highly inflected language: the same root can derive dozens of forms through prefixes, suffixes, and internal vowel changes, along with complex dialectal variations; Hebrew everyday writing typically omits vowel marks (niqqud), requiring the model to infer correct pronunciation and meaning from context. These characteristics require the model to have a larger language-specific parameter space, which directly conflicts with the size constraints of on-device models, making the engineering adaptation workload for RTL languages significantly greater than for Latin-based languages.

The Practical Realities of Commercial Priorities

From a product strategy perspective, Google typically prioritizes languages with large user bases and high commercial value, such as English, Japanese, German, French, and Spanish. Relatively niche languages like Hebrew (roughly 9 million speakers worldwide) tend to fall toward the back of the support queue.

This also explains why the Pixel 10 user felt uncertain about "whether there's hope in the next year or two"—official sources usually don't provide a clear timeline for supporting minority languages.

What Can Users Reasonably Expect?

Short Term: Cautiously Optimistic

Based on historical experience, Google has been steadily expanding Gemini's language coverage. The cloud version of Gemini already supports dozens of languages, including Arabic and Hebrew, accumulating data and technical foundations for the multilingualization of on-device models.

But one thing must be made clear: cloud support does not equal on-device support. As a compressed model, Gemini Nano's language expansion requires independent engineering investment, and its progress typically lags behind the cloud version.

Long Term: Evolving Alongside Hardware and Model Technology

As phone NPU computing power continues to improve, along with advances in model compression and quantization techniques, future versions of Gemini Nano are expected to accommodate more languages while remaining lightweight. Organizations like Meta and Mozilla have already begun attempting to bridge the AI language gap through innovative projects, and the industry's technical accumulation for multilingual on-device deployment is accelerating.

Meta's MMS (Massively Multilingual Speech) project, released in 2023, is based on the wav2vec 2.0 framework. Using religious texts (such as Bible translations) as multilingual audio-text alignment data, it expanded speech recognition coverage to more than 1,100 languages and speech synthesis to about 1,100 languages, making it one of the open-source speech models with the widest language coverage available today. Mozilla's Common Voice project, on the other hand, uses a crowdsourcing approach to collect speech data for minority languages, having so far accumulated community-contributed corpora in over 100 languages. Together, these two projects represent the systematic efforts of academia and the open-source community to bridge the AI language gap, and they also provide an important foundation of training data for on-device multilingual models. The industry generally expects the multilingual capabilities of on-device models to improve significantly within the next two to three years.

For users who want to use Hebrew or Arabic, one practical alternative is: in scenarios requiring high-quality multilingual processing, prioritize the connected Gemini app (cloud model) rather than relying on the on-device Nano.

Conclusion: The Road to Inclusive On-Device AI Is Still Being Paved

This Reddit user's question reflects a shared challenge facing the entire on-device AI industry—how to achieve true language equality within limited device resources.

At present, Google has not provided an official timeline for Gemini Nano support for languages like Hebrew and Arabic, so users should not have excessively high expectations that it will be "achievable soon." But based on technical trends and Google's continued investment, there is reasonable hope of seeing substantial improvements within a one-to-two-year timeframe.

For Pixel 10 users right now, the recommended strategy is: make full use of the on-device features for already-supported languages such as English, flexibly leverage cloud services for multilingual needs, and keep an eye on version updates for Android AICore and Gemini.