Tag Archives: language

Per-App Language Preferences – Part 2

Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)


In part 1 of the Per-App Language Preferences blog, we discussed what the feature is, how developers benefit from it, how to implement the feature, and the strong business impact of catering to multilingual users. In this part of the blog, we'll discuss how various top apps migrated to the Per-App Languages Feature and how it benefited them.

Developer Success Stories

Here are some top apps that migrated to the Per-App Languages Preferences APIs. Let’s have a look at them.
LinkedIn Logo

LinkedIn is a business and employment oriented online platform that is primarily used for professional networking and career development. It bridges the gap between an employer and a job seeker, by providing both a common ground to connect. LinkedIn operates over a huge set of 875+ M registered users spread across more than 200 countries and territories.

Due to the several regions they cover, it becomes important to support multiple languages in the app. LinkedIn supports 26 Languages in their app right now, and this brings forward an opportunity to provide the users with the best experiences of latest android features. With this as the target, the LinkedIn team invested their efforts in migrating to the new Per-App Language Preferences APIs, and went ahead to provide their consumers the complete flexibility and features of Android 13. The team also quoted, “It was an easy integration with minimal code changes”.

MyJio Logo

MyJio is the-one-stop destination for recharges, managing accounts & Jio devices, UPI & payments, entertainment services with movies, music, news, games, quizzes & a lot more. With over 500 M+ total installs spread across the globe, MyJio aims to provide its users better access to a variety of utilities. Also as the user-base of MyJio is quite vast, the app supports a total of over 12+ Languages. With these many features and a wide diversity of active multilingual users, MyJio has a strong reason to localize their app using the best practices.

MyJio developers implemented the Per App Language Preferences APIs right along with the Android 13 release, allowing their users the flexibility to select a language for their app from system settings as well.

One of the major use-cases was to retain user's language preference, when users switch devices and then log in again from the same account. In this case, when the data is restored from a previous backup, the language preference is also restored along with the rest of the data, maintaining the seamless MyJio user experience across devices. This shows the API's flexibility to work well with other Android features like Backup and Restore, and helps developers give their users a better user experience.

Zomato Logo
With over 16.7M+ monthly transacting customers in more than 1000 cities across India, it is one of the most popular food ordering and restaurant discovery services in the region. This also means that the app is used in several languages. Zomato currently supports over 15 languages on its app.

The Zomato team wanted to make the user experience for users across geographies to be very seamless and delightful. Localizing the app based on the region and user preference was an important step in this direction. Zomato was quick to respond to the changes that were introduced in Android 13. They went ahead and migrated their language-switching logic to Per-App Language Preferences, within a week. Thereby helping their users find an easy way to use Zomato in their preferred language.


At Zomato, providing the best customer experience possible is the core of our business and we believe localization is very critical in giving our customers a pleasant experience on the platform. Our team integrated with the new A13 Per-App Language Preferences API provided by Google to make it easy for our users to switch their preferred language on Zomato.

The ease of integrating the API helped us get it done effortlessly in less than a week’s time. Backward compatibility and stability of the API ensured that we are not compromising on the experience of our customers. With this, we hope to provide a better experience to the customer in their journey of online ordering via Zomato.

OkCredit Logo

OkCredit is a credit management app with over 50M+ downloads, having total annual transactions of around 50 Billion USD on the app. As OKCredit supports both local and large-scale businesses and also around 10+ languages in their app, it was critical for them to support the ability to seamlessly switch the app language so that more users are able to onboard on their platform.

The developers from OkCredit have always been quick to adopt changes introduced in Android. They recently adopted the Per-App Language Preferences APIs within the timeframe of a week, providing their end users a better and more seamless experience around switching their app languages at their convenience.


The demand for using apps in vernacular language is steadily growing in India. After Google announced Per-App Language Preferences recently, it was a straightforward decision to integrate them. The implementation was straightforward, stable, and compatible with older Android versions.


We saw that some top apps have implemented the Per-App Language Preferences APIs in their apps and have also circulated the updates out to the users. This easy migration was possible in such a short timespan due to the low amount of effort investment and minimal code changes required. Lastly, here are some resources that can help you understand the feature better.

  1. Per-App Language Preferences
  2. Sample App ( Compose )
  3. Sample App ( Views )
  4. Per-app language preferences (YouTube Video)

Per-App Language Preferences – Part 1

Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)What if you have a set of users who are quite fluent in English, Hindi, and Spanish, and they have a news app on their phones and prefer to read the news in Hindi? For their texting app, they prefer Spanish as they have some friends and family who they text with in Spanish. But for ease of access, they still prefer their device to be in English. Now there are many such use-cases where the users might want their app languages to be different from their system language. Interesting!

Starting with Android 13, we have included one of the most-requested features from users, Per-App Language Preferences. It lets users switch app languages from System settings, providing users with better control over their language choices for different apps, irrespective of the system language.
A cellphone screen displaying App language preferences in system settings for the YouTube app

Build for your multilingual users

This blog focuses on how to integrate the Per-App Language Preferences API in your app to provide your users the flexibility to choose different languages for different apps.

1.    Users can change the language settings from system settings by selecting: 

Settings → System → Languages & Input → App Languages → [Select the desired App] → [Select the desired Language]

NOTE: Only those apps that have opted in for the feature by specifying the locale_config.xml file (more on this below), will appear in system settings.

A cellphone screen demonstrating finding the language settings from system settings by selecting Settings → System → Languages & Input → App Languages → [Select the desired App] → [Select the desired Language]
2.    If your app already has an in-app language picker, you can integrate the Per-App Language Preferences API to leverage the full platform support. For pre-Android 13 users, the system settings won’t be visible, but developers can still provide an in-app language picker.

A cellphone screen demonstrating integrating the Per-App Language prefences API for an app which already has an in-app language picker

How to integrate this feature in your app?

There are 5 steps that need to be followed while working on the Per-App Language Preferences feature, listed here →


1.    Create locale_config.xml file

Create a new file in values/xml/ directory and name it as locale_config.xml. This file should contain a list of all the locales that are supported by the app. The list element should be a string containing a locale tag.

NOTE: The locale tags must follow the BCP47 syntax, which is usually {language subtag}–{script subtag}–{country subtag}. Anything other than that will be filtered out by the system and won't be visible in the system settings.


<?xml version="1.0" encoding="utf-8"?>
<locale-config xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- English -->
    <locale android:name="en"/>

    <!-- Japanese (Japan) -->          
    <locale android:name="ja-JP"/>

    <!-- Chinese (Macao) in Simplified Script -->
    <locale android:name="zh-Hans-MO"/>

    <!-- Chinese (Taiwan) in Traditional Script -->
    <locale android:name="zh-Hant-TW"/>  

2.    Add the locale_config in the AndroidManifest.xml

Specify this locale_config.xml file in the app’s AndroidManifest.xml



After steps 1 & 2, your users will be able to discover and set their language preference for your app from system settings on devices running Android 13 or higher. In case your users are on devices running on versions lower than Android 13, you can provide an in-app language picker. Optionally, you can also include the same language picker in your app for devices running Android 13 or higher. When your app includes an in-app language picker, it's important for the user's preferences to be in sync between the system and the app. This is where the AndroidX APIs come into the picture. Read on to learn how to create an in-app language picker.

3. Add the libraries

Use the latest version of AppCompat Library

build.gradle (app)

def latestAppCompatVersion =  “1.6.0-rc01”

dependencies {
    implementation "androidx.appcompat:appcompat:$latestAppCompatVersion"
    implementation "androidx.appcompat:appcompat-resources:$latestAppCompatVersion"

4. Use AndroidX APIs

Use the APIs in your code to set and get the app locales.


val appLocale: LocaleListCompat = LocaleListCompat.forLanguageTags("xx-YY")

// Call this on the main thread as it may require Activity.restart()

// Call this to get the selected locale and display it in your App
val selectedLocale = AppCompatDelegate.getApplicationLocales()[0]

NOTE: These APIs are also backward compatible, so even if the app is being used on Android 12 or lower, the APIs would still behave the same, and no additional checks for OS versions are required in your code.

5. Delegate storage to AndroidX

Let AndroidX handle the locale storage so that the user's preference persists.


            android:value="true" />

Steps 3, 4, & 5 above demonstrate the minimum components needed to create an in-app language picker.

And with this, your app can now support locale switching.

Additional things to take care of while migrating to the API

Earlier, developers had to handle the user's preferences on their own, either by using SharedPreferences, storing the data on a server, or other app logic. With the new APIs, there is no need to handle this separately. So when you are using these APIs, AndroidX is already taking care of the storage part, but what happens when the app is opened for the first time after a user updates their device to Android 13 or higher?

In this case, the system won’t be aware of the user’s preferences for the app language and thus it will map the app to the default system language. To avoid this, developers need to add some one-time migration logic so that their users don’t have to set the language again when they update the app.

// Specify the constants to be used in the below code snippets

companion object {

    // Constants for SharedPreference File
    const val PREFERENCE_NAME = "shared_preference"
    const val PREFERENCE_MODE = Context.MODE_PRIVATE

    // Constants for SharedPreference Keys
    const val FIRST_TIME_MIGRATION = "first_time_migration"
    const val SELECTED_LANGUAGE = "selected_language"

    // Constants for SharedPreference Values
    const val STATUS_DONE = "status_done"

// Utility method to put a string in a SharedPreference
private fun putString(key: String, value: String) {
    val editor = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE).edit()
    editor.putString(key, value)

// Utility method to get a string from a SharedPreference
private fun getString(key: String): String? {
    val preference = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE)
    return preference.getString(key, null)

// Check if the migration has already been done or not

   // Fetch the selected language from wherever it was stored. In this case it’s SharedPref

   // In this case let’s assume that it was stored in a key named SELECTED_LANGUAGE
  getString(SELECTED_LANGUAGE)?.let { it

      // Set this locale using the AndroidX library that will handle the storage itself
      val localeList = LocaleListCompat.forLanguageTags(it)

      // Set the migration flag to ensure that this is executed only once


What flexibility does the feature provide to the users and developers?

Here are a few things that might prove to be beneficial for you users.

  1. All devices running Android 13 or higher will have a common place for users to discover and change the language of their apps.
  2. Although the system settings are limited to the devices running Android 13 or higher, the AndroidX APIs are backwards compatible. Thus, there is no requirement to add OS Version checks in your code while building for your multilingual users.
  3. Developers do not need to handle configuration changes separately or worry about storing the user's selected language every time. The API handles configuration changes and stores the language preferences for you.
  4. Works with other Android features like Backup and restore. If a user switches to a new device and restores the previously backed up data, your app will retain the user’s last preferred language, thus providing your users with a better and more seamless experience.


With that, most parts of the feature are covered. So let’s have a quick recap on what we discussed in today’s read.

  1. A quick read on what Per-App Language Preferences offer to multilingual users and app developers.
  2. What end users will see on their devices.
  3. How to migrate your app to the Per-App Language Preferences APIs.
  4. A few things that need to be taken care of while migrating to the APIs to ensure a better user experience.
  5. Lastly, the benefits that end users and developers can leverage from this feature.


  1. Per-App Language Preferences
  2. Sample App ( Compose )
  3. Sample App ( Views )
  4. Per-App Language Preferences (YouTube Video)

Search, explore and shop the world’s information, powered by AI

AI advancements push the boundaries of what Google products can do. Nowhere is this clearer than at the core of our mission to make information more accessible and useful for everyone.

We've spent more than two decades developing not just a better understanding of information on the web, but a better understanding of the world. Because when we understand information, we can make it more helpful  — whether you’re a remote student learning a complex new subject, a caregiver looking for trusted information on COVID vaccines or a parent searching for the best route home.

Deeper understanding with MUM

One of the hardest problems for search engines today is helping you with complex tasks — like planning what to do on a family outing. These often require multiple searches to get the information you need. In fact, we find that it takes people eight searches on average to complete complex tasks.

With a new technology called Multitask Unified Model, or MUM, we're able to better understand much more complex questions and needs, so in the future, it will require fewer searches to get things done. Like BERT, MUM is built on a Transformer architecture, but it’s 1,000 times more powerful and can multitask in order to unlock information in new ways. MUM not only understands language, but also generates it. It’s trained across 75 different languages and many different tasks at once, allowing it to develop a more comprehensive understanding of information and world knowledge than previous models. And MUM is multimodal, so it understands information across text and images and in the future, can expand to more modalities like video and audio.

Imagine a question like: “I’ve hiked Mt. Adams and now want to hike Mt. Fuji next fall, what should I do differently to prepare?” This would stump search engines today, but in the future, MUM could understand this complex task and generate a response, pointing to highly relevant results to dive deeper. We’ve already started internal pilots with MUM and are excited about its potential for improving Google products.


Information comes to life with Lens and AR

People come to Google to learn new things, and visuals can make all the difference. Google Lens lets you search what you see — from your camera, your photos or even your search bar. Today we’re seeing more than 3 billion searches with Lens every month, and an increasingly popular use case is learning. For example, many students might have schoolwork in a language they aren't very familiar with. That’s why we’re updating the Translate filter in Lens so it’s easy to copy, listen to or search translated text, helping students access education content from the web in over 100 languages.


Google Lens’s Translate filter applied to homework.

AR is also a powerful tool for visual learning. With the new AR athletes in Search, you can see signature moves from some of your favorite athletes in AR — like Simone Biles’s famous balance beam routine.

Simone Biles’s balance beam routine surfaced by the AR athletes in Search feature.

Evaluate information with About This Result 

Helpful information should be credible and reliable, and especially during moments like the pandemic or elections, people turn to Google for trustworthy information. 


Our ranking systems are designed to prioritize high-quality information, but we also help you evaluate the credibility of sources, right in Google Search. Our About This Result feature provides details about a website before you visit it, including its description, when it was first indexed and whether your connection to the site is secure. 



This month, we’ll start rolling out About This Result to all English results worldwide, with more languages to come. Later this year, we’ll add even more detail, like how a site describes itself, what other sources are saying about it and related articles to check out. 


Exploring the real world with Maps

Google Maps transformed how people navigate, explore and get things done in the world — and we continue to push the boundaries of what a map can be with industry-first features like AR navigation in Live View at scale. We recently announced we’re on track to launch over 100 AI-powered improvements to Google Maps by the end of year, and today, we’re introducing a few of the newest ones. Our new routing updates are designed to reduce the likelihood of hard-braking on your drive using machine learning and historical navigation information — which we believe could eliminate over 100 million hard-braking events in routes driven with Google Maps each year.


If you’re looking for things to do, our more tailored map will spotlight relevant places based on time of day and whether or not you’re traveling. Enhancements to Live View and detailed street maps will help you explore and get a deep understanding of an area as quickly as possible. And if you want to see how busy neighborhoods and parts of town are, you’ll be able to do this at a glance as soon as you open Maps.

More ways to shop with Google 

People are shopping across Google more than a billion times per day, and our AI-enhanced Shopping Graph — our deep understanding of products, sellers, brands, reviews, product information and inventory data — powers many features that help you find exactly what you’re looking for.

Because shopping isn’t always a linear experience, we’re introducing new ways to explore and keep track of products. Now, when you take a screenshot, Google Photos will prompt you to search the photo with Lens, so you can immediately shop for that item if you want. And on Chrome, we’ll help you keep track of shopping carts you’ve begun to fill, so you can easily resume your virtual shopping trip. We're also working with retailers to surface loyalty benefits for customers earlier, to help inform their decisions.

Last year we made it free for merchants to sell their products on Google. Now, we’re introducing a new, simplified process that helps Shopify’s 1.7 million merchants make their products discoverable across Google in just a few clicks.  

Whether we’re understanding the world’s information, or helping you understand it too, we’re dedicated to making our products more useful every day. And with the power of AI, no matter how complex your task, we’ll be able to bring you the highest quality, most relevant results.  

Posted by Prabhakar Raghavan, Senior Vice President

Improving Indian Language Transliterations in Google Maps

Nearly 75% of India’s population — which possesses the second highest number of internet users in the world — interacts with the web primarily using Indian languages, rather than English. Over the next five years, that number is expected to rise to 90%. In order to make Google Maps as accessible as possible to the next billion users, it must allow people to use it in their preferred language, enabling them to explore anywhere in the world.

However, the names of most Indian places of interest (POIs) in Google Maps are not generally available in the native scripts of the languages of India. These names are often in English and may be combined with acronyms based on the Latin script, as well as Indian language words and names. Addressing such mixed-language representations requires a transliteration system that maps characters from one script to another, based on the source and target languages, while accounting for the phonetic properties of the words as well.

For example, consider a user in Ahmedabad, Gujarat, who is looking for a nearby hospital, KD Hospital. They issue the search query, કેડી હોસ્પિટલ, in the native script of Gujarati, the 6th most widely spoken language in India. Here, કેડી (“kay-dee”) is the sounding out of the acronym KD, and હોસ્પિટલ is “hospital”. In this search, Google Maps knows to look for hospitals, but it doesn't understand that કેડી is KD, hence it finds another hospital, CIMS. As a consequence of the relative sparsity of names available in the Gujarati script for places of interest (POIs) in India, instead of their desired result, the user is shown a result that is further away.

To address this challenge, we have built an ensemble of learned models to transliterate names of Latin script POIs into 10 languages prominent in India: Hindi, Bangla, Marathi, Telugu, Tamil, Gujarati, Kannada, Malayalam, Punjabi, and Odia. Using this ensemble, we have added names in these languages to millions of POIs in India, increasing the coverage nearly twenty-fold in some languages. This will immediately benefit millions of existing Indian users who don't speak English, enabling them to find doctors, hospitals, grocery stores, banks, bus stops, train stations and other essential services in their own language.

Transliteration vs. Transcription vs. Translation

Our goal was to design a system that will transliterate from a reference Latin script name into the scripts and orthographies native to the above-mentioned languages. For example, the Devanagari script is the native script for both Hindi and Marathi (the language native to Nagpur, Maharashtra). Transliterating the Latin script names for NIT Garden and Chandramani Garden, both POIs in Nagpur, results in एनआईटी गार्डन and चंद्रमणी गार्डन, respectively, depending on the specific language’s orthography in that script.

It is important to note that the transliterated POI names are not translations. Transliteration is only concerned with writing the same words in a different script, much like an English language newspaper might choose to write the name Горбачёв from the Cyrillic script as “Gorbachev” for their readers who do not read the Cyrillic script. For example, the second word in both of the transliterated POI names above is still pronounced “garden”, and the second word of the Gujarati example earlier is still “hospital” — they remain the English words “garden” and “hospital”, just written in the other script. Indeed, common English words are frequently used in POI names in India, even when written in the native script. How the name is written in these scripts is largely driven by its pronunciation; so एनआईटी from the acronym NIT is pronounced “en-aye-tee”, not as the English word “nit”. Knowing that NIT is a common acronym from the region is one piece of evidence that can be used when deriving the correct transliteration.

Note also that, while we use the term transliteration, following convention in the NLP community for mapping directly between writing systems, romanization in South Asian languages regardless of the script is generally pronunciation-driven, and hence one could call these methods transcription rather than transliteration. The task remains, however, mapping between scripts, since pronunciation is only relatively coarsely captured in the Latin script for these languages, and there remain many script-specific correspondences that must be accounted for. This, coupled with the lack of standard spelling in the Latin script and the resulting variability, is what makes the task challenging.

Transliteration Ensemble

We use an ensemble of models to automatically transliterate from the reference Latin script name (such as NIT Garden or Chandramani Garden) into the scripts and orthographies native to the above-mentioned languages. Candidate transliterations are derived from a pair of sequence-to-sequence (seq2seq) models. One is a finite-state model for general text transliteration, trained in a manner similar to models used by Gboard on-device for transliteration keyboards. The other is a neural long short-term memory (LSTM) model trained, in part, on the publicly released Dakshina dataset. This dataset contains Latin and native script data drawn from Wikipedia in 12 South Asian languages, including all but one of the languages mentioned above, and permits training and evaluation of various transliteration methods. Because the two models have such different characteristics, together they produce a greater variety of transliteration candidates.

To deal with the tricky phenomena of acronyms (such as the “NIT” and “KD” examples above), we developed a specialized transliteration module that generates additional candidate transliterations for these cases.

For each native language script, the ensemble makes use of specialized romanization dictionaries of varying provenance that are tailored for place names, proper names, or common words. Examples of such romanization dictionaries are found in the Dakshina dataset.

Scoring in the Ensemble

The ensemble combines scores for the possible transliterations in a weighted mixture, the parameters of which are tuned specifically for POI name accuracy using small targeted development sets for such names.

For each native script token in candidate transliterations, the ensemble also weights the result according to its frequency in a very large sample of on-line text. Additional candidate scoring is based on a deterministic romanization approach derived from the ISO 15919 romanization standard, which maps each native script token to a unique Latin script string. This string allows the ensemble to track certain key correspondences when compared to the original Latin script token being transliterated, even though the ISO-derived mapping itself does not always perfectly correspond to how the given native script word is typically written in the Latin script.

In aggregate, these many moving parts provide substantially higher quality transliterations than possible for any of the individual methods alone.


The following table provides the per-language quality and coverage improvements due to the ensemble over existing automatic transliterations of POI names. The coverage improvement measures the increase in items for which an automatic transliteration has been made available. Quality improvement measures the ratio of updated transliterations that were judged to be improvements versus those that were judged to be inferior to existing automatic transliterations.


Coverage Improvement

Quality Improvement































* Unknown / No Baseline.


As with any machine learned system, the resulting automatic transliterations may contain a few errors or infelicities, but the large increase in coverage in these widely spoken languages marks a substantial expansion of the accessibility of information within Google Maps in India. Future work will include using the ensemble for transliteration of other classes of entities within Maps and its extension to other languages and scripts, including Perso-Arabic scripts, which are also commonly used in the region.

Acknowledgments: This work was a collaboration between the authors and Jacob Farner, Jonathan Herbert, Anna Katanova, Andre Lebedev, Chris Miles, Brian Roark, Anurag Sharma, Kevin Wang, Andy Wildenberg, and many others.

Posted by Cibu Johny, Software Engineer, Google Research and Saumya Dalal, Product Manager, Google Geo

The Go language turns 10: A Look at Go’s Growth in the Enterprise

Posted by Steve Francia, Go TeamGo's gopher mascot

The Go gopher was created by renowned illustrator Renee French. This image is adapted from a drawing by Egon Elbre.

November 10 marked Go’s 10th anniversary—a milestone that we are lucky enough to celebrate with our global developer community.

The Gopher community will be celebrating Go’s 10th anniversary at conferences such as Gopherpalooza in Mountain View and KubeCon in San Diego, and dozens of meetups around the world.

In recognition of this milestone, we’re taking a moment to reflect on the tremendous growth and progress Go (also known as golang) has made: from its creation at Google and open sourcing, to many early adopters and enthusiasts, to the global enterprises that now rely on Go everyday for critical workloads.

New to Go?

Go is an open-source programming language designed to help developers build fast, reliable, and efficient software at scale. It was created at Google and is now supported by over 2100 contributors, primarily from the open-source community. Go is syntactically similar to C, but with the added benefits of memory safety, garbage collection, structural typing, and CSP-style concurrency.

Most importantly, Go was purposefully designed to improve productivity for multicore, networked machines and large codebases—allowing programmers to rapidly scale both software development and deployment.

Millions of Gophers!

Today, Go has more than a million users worldwide, ranging across industries, experience, and engineering disciplines. Go’s simple and expressive syntax, ease-of-use, formatting, and speed have helped it become one of the fastest growing languages—with a thriving open source community.

As Go’s use has grown, more and more foundational services have been built with it. Popular open source applications built on Go include Docker, Hugo, Kubernetes. Google’s hybrid cloud platform, Anthos, is also built with Go.

Go was first adopted to support large amounts of Google’s services and infrastructure. Today, Go is used by companies including, American Express, Dropbox, The New York Times, Salesforce, Target, Capital One, Monzo, Twitch, IBM, Uber, and Mercado Libre. For many enterprises, Go has become their language of choice for building on the cloud.

An Example of Go In the Enterprise

One exciting example of Go in action is at MercadoLibre, which uses Go to scale and modernize its ecommerce ecosystem, improve cost-efficiencies, and system response times.

MercadoLibre’s core API team builds and maintains the largest APIs at the center of the company’s microservices solutions. Historically, much of the company’s stack was based on Grails and Groovy backed by relational databases. However this big framework with multiple layers was soon found encountering scalability issues.

Converting that legacy architecture to Go as a new, very thin framework for building APIs streamlined those intermediate layers and yielded great performance benefits. For example, one large Go service is now able to run 70,000 requests per machine with just 20 MB of RAM.

“Go was just marvelous for us,” explains Eric Kohan, Software Engineering Manager at MercadoLibre. “It’s very powerful and very easy to learn, and with backend infrastructure has been great for us in terms of scalability.”

Using Go allowed MercadoLibre to cut the number of servers they use for this service to one-eighth the original number (from 32 servers down to four), plus each server can operate with less power (originally four CPU cores, now down to two CPU cores). With Go, the company obviated 88 percent of their servers and cut CPU on the remaining ones in half—producing a tremendous cost-savings.

With Go, MercadoLibre’s build times are three times (3x) faster and their test suite runs an amazing 24 times faster. This means the company’s developers can make a change, then build and test that change much faster than they could before.

Today, roughly half of Mercadolibre's traffic is handled by Go applications.

"We really see eye-to-eye with the larger philosophy of the language," Kohan explains. "We love Go's simplicity, and we find that having its very explicit error handling has been a gain for developers because it results in safer, more stable code in production."

Visit go.dev to Learn More

We’re thrilled by how the Go community continues to grow, through developer usage, enterprise adoption, package contribution, and in many other ways.

Building off of that growth, we’re excited to announce go.dev, a new hub for Go developers.

There you’ll find centralized information for Go packages and modules, a wealth of learning resources to get started with the language, and examples of critical use cases and case studies of companies using Go.

MercadoLibre’s recent experience is just one example of how Go is being used to build fast, reliable, and efficient software at scale.

You can read more about MercadoLibre’s success with Go in the full case study.

AdSense now understands Marathi

Today, we’re excited to announce the addition of Marathi, a language spoken by over 80 millions people in Maharashtra, India and many other countries around the world, to the family of AdSense supported languages.

The interest for Marathi language content has been growing steadily over the last few years. With this launch, AdSense provides an easy way for publishers to monetize the content they create in Marathi, and advertisers can connect to a Marathi speaking audience with relevant ads.

To start monetizing your Marathi content website with Google AdSense:

  1. Check the AdSense Program policies and make sure your site is compliant.
  2. Sign up for an AdSense account
  3. Add the AdSense code to start displaying relevant ads to your users.

Welcome to AdSense! Sign Up now!

Posted by AdSense Internationalization Team

Indigenous speakers in Canada share their languages on Google Earth

Of the 7,000 languages spoken around the globe, 2,680 Indigenous languages—more than one third of
the world's languages—are in danger of disappearing. The United Nations declared 2019 the
International Year of Indigenous Languages to raise awareness about these languages and their
contribution to global diversity. To help preserve them, our new Google Earth tour,
Celebrating Indigenous Languages, shares audio recordings from more than 50 Indigenous language

“It is a human right to be able to speak your own language,” says Tania Haerekiterā Tapueluelu
Wolfgramm, a Māori and Tongan person who works as an educator and activist in Aotearoa--the Māori
name for New Zealand--and other Pacific countries. “You don’t have a culture without the language.”

Tania is one of several dozen Indigenous language speakers, advocates and educators who helped
create the tour. Thanks to their contributions, people can click on locations meaningful to Indigenous
speakers and hear people offer traditional greetings, sing songs, or say common words and phrases in
their languages. 

“Hundreds of languages are a few days away from never being spoken or heard again,” says Tania.
“By putting Indigenous languages on the global stage, we reclaim our right to talk about our lives in our
own words. It means everything to us.”
Listen to more than 50 Indigenous language speakers globally in Google Earth

The healing power of speaking one’s own language

The people who recorded audio in their languages and connected Google with Indigenous speakers
each have their own story about why revitalizing Indigenous languages strikes a chord for them. 

For Arden Ogg, director of Canada’s Cree Literacy Network, and Dolores Greyeyes Sand, a Plains Cree
person and Cree language teacher, the focus is on providing resources for language learners. For Brian
Thom, a cultural anthropologist and professor at the University of Victoria in British Columbia, the
interest grew out of his work helping Indigenous communities map their traditional lands

Brian asked yutustanaat, a member of the Snuneymuxw First Nation and a language teacher in British
Columbia, to record the hul’q’umi’num’ language. “Our language is very healing,” says yutustanaat. “It
brings out caring in our people and helps our students be strong, because the language comes from
the heart.” In her recording, yutustanaat speaks the traditional hul’q’umi’num’ greeting:
‘i ch ‘o’ ‘uy’ ‘ul’ or “How are you?”

By using their languages—and sharing them with the rest of the world—Indigenous people create closer
connections to a culture that is often endangered or has outright disappeared. 

Wikuki Kingi, a Māori Master Carver, recorded traditional chants in Te Reo Māori, an Eastern Polynesian
language indigenous to New Zealand. He says, “Speaking Te Reo Māori connects me to my relatives, to
the land, rivers, and the ocean, and it can take me to another time and place.” 

On the right, yutustanaat, a Snuneymuxw First Nation member, records the hul’q’umi’num’ language
with student Beatrix Taylor. Listen to it in the Celebrating Indigenous Languages collection.
Photo credit: Brian Thom

Ensuring that generations to come will hear their languages

“I do this not for myself, but for my children and grandchildren, so that in the future, they’ll hear our
language,” says Dolores, who recorded audio in her native Plains Cree

To ensure that future generations hear and speak Indigenous languages, more needs to be done to
support their revitalization. Tania Wolfgramm suggests checking out how her nonprofit organization,
Global Reach Initiative & Development Pacific, uses technology to connect far-flung Indigenous people
to their traditional communities—like bringing Google Street View to the remote island of Tonga. Arden
Ogg directs people interested in Indigenous languages to the Cree Literacy Network, which publishes
books in Cree and English to facilitate language learning. And a video from the University of Victoria
suggests five ways to support Indigenous language revitalization, such as learning words and phrases
using smartphone apps, and learning the names of rivers, mountains and towns in the local Indigenous

This initial collection of audio recordings in Google Earth only scratches the surface of the world’s
thousands of Indigenous languages. If you’d like to contribute your language to this collection in the
future, please share your interest.    

The latest Android App Bundle updates including the additional languages API

Posted by Wojtek Kaliciński, Developer Advocate, Android

Last year, we launched Android App Bundles and Google Play's Dynamic Delivery to introduce modular development, reduce app size and streamline the release process. Since then, we've seen developers quickly adopt this new app model in over 60,000 production apps. We've been excited to see developers experience significant app size savings and reductions in the time needed to manage each release, and have documented these benefits in case studies with Duolingo and redBus.

Thank you to everyone who took the time to give us feedback on our initial launch. We're always open to new ideas, and today, we're happy to announce some new improvements based on your suggestions:

  • A new additional languages install API, which supports in-app language pickers
  • A streamlined publishing process for instant-enabled app bundles
  • A new enrollment option for app signing by Google Play
  • The ability to permanently uninstall dynamic feature modules that are included in your app's initial install

Additional languages API

When you adopt the Android App Bundle as the publishing format for your app, Google Play is able to optimize the installation by delivering only the language resources that match the device's system locales. If a user changes the system locale after the app is installed, Play automatically downloads the required resources.

Some developers choose to decouple the app's display language from the system locale by adding an in-app language switcher. With the latest release of the Play Core library (version 1.4.0), we're introducing a new additional languages API that makes it possible to build in-app language pickers while retaining the full benefits of smaller installs provided by using app bundles.

With the additional languages API, apps can now request the Play Store to install resources for a new language configuration on demand and immediately start using it.

Get a list of installed languages

The app can get a list of languages that are already installed using the SplitInstallManager#getInstalledLanguages() method.

val splitInstallManager = SplitInstallManagerFactory.create(context)
val langs: Set<String> = splitInstallManager.installedLanguages

Requesting additional languages

Requesting an additional language is similar to requesting an on demand module. You can do this by specifying a language in the request through SplitInstallRequest.Builder#addLanguage(java.util.Locale).

val installRequestBuilder = SplitInstallRequest.newBuilder()

The app can also monitor install success with callbacks and monitor the download state with a listener, just like when requesting an on demand module.

Remember to handle the SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION state. Please note that there was an API change in a recent Play Core release, which means you should use the new SplitInstallManager#startConfirmationDialogForResult() together with Activity#onActivityResult(). The previous method of using SplitInstallSessionState#resolutionIntent() with startIntentSender() has been deprecated.

Check out the updated Play Core Library documentation for more information on how to access the newly installed language resources in your activity.

We've also updated our dynamic features sample on GitHub with the additional languages API, including how to store the user's language preference and apply it to your activities at startup.

Please note that while the additional languages API is now available to all developers, on demand modules are in a closed beta for the time being. You can experiment with on demand modules in your internal, open, and closed test tracks, while we work with our partners to make sure this feature is ready for production apps.

Instant-enabled App Bundle

In Android Studio 3.3, we introduced a way to build app bundles that contain both the regular, installed version of your app as well as a Google Play Instant experience for modules marked with the dist:instant="true" attribute in their AndroidManifest.xml:

<manifest ... xmlns:dist="http://schemas.android.com/apk/distribution">
    <dist:module dist:instant="true" />

Even though you could use a single project to generate the installed and instant versions of your app, up until now, developers were still required to use product flavors in order to build two separate app bundles and upload both to Play.

We're happy to announce that we have now removed this restriction. It's now possible to upload a single, unified app bundle artifact, containing modules enabled for the instant experience. This functionality is now available for everyone.

After you build an instant-enabled app bundle, upload it to any track on the Play Console, and you'll be able to select it when creating a new instant app release. This also means that the installed and instant versions of your app no longer need different version codes, which will simplify the release workflow.

Opt in to app signing by Google Play

You need to enable app signing by Google Play to publish your app using an Android App Bundle and automatically benefit from Dynamic Delivery optimizations. It is also a more secure way to manage your signing key, which we recommend to everyone, even if you want to keep publishing regular APKs for now.

Based on your feedback, we've revamped the sign-up flow for new apps to make it easier to initialize the key you want to use for signing your app.

Now developers can explicitly choose to upload their existing key without needing to upload a self-signed artifact first. You can also choose to start with a key generated by Google Play, so that the key used to locally sign your app bundle can become your upload key.

Read more about the new flow.

Permanent uninstallation of install time modules

We have now added the ability to permanently uninstall dynamic feature modules that are included in your app's initial install.

This is a behavior change, which means you can now call the existing SplitInstallManager#deferredUninstall() API on modules that set onDemand="false". The module will be permanently uninstalled, even when the app is updated.

This opens up new possibilities for developers to further reduce the installed app size. For example, you can now uninstall a heavy sign-up module or any other onboarding content once the user completes it. If the user navigates to a section of your app that has been uninstalled, you can reinstall it using the standard on demand modules install API.

We hope you enjoy these improvements and test them out in your apps. Continue to share your feedback as we work to make these features even more useful for you!

How useful did you find this blog post?

Budou: Automatic Japanese line breaking tool

Today we are pleased to introduce Budou, an automatic line breaking tool for Japanese. What is a line breaking tool and why is it necessary? English uses spacing and hyphenation as cues to allow for beautiful, aka more legible, line breaks. Japanese, which has none of these, is notoriously more difficult. Breaks occur randomly, usually in the middle of a word.

This is a long standing issue in Japanese typography on the web, and results in degradation of readability. We can specify the place which line breaks can occur with CSS coding, but this is a non-trivial manual process which requires Japanese vocabulary and knowledge of grammar.

Budou automatically translates Japanese sentences into organized HTML code with meaningful chunks wrapped in non-breaking markup so as to semantically control line breaks. Budou uses Cloud Natural Language API to analyze the input sentence, and it concatenates proper words in order to produce meaningful chunks utilizing PoS (part-of-speech) tagging and syntactic information. Budou outputs HTML code by wrapping the chunks in a SPAN tag. By specifying their display property as inline-block in CSS, semantic units will no longer be split at the end of a line.

Budou is a simple Python script that runs each sentence through the Cloud Natural Language API. It can easily be extended as a custom filter for template engines, or as a task for runners such as Grunt and Gulp. The latest version also caches the response so no duplicate requests are sent. If you are using Budou for a static website, you can process your HTML code before deployment.

Budou is aimed to be used in relatively short sentences such as titles and headings. Screen readers may read a sentence by splitting the chunks wrapped by SPAN tag or split by WBR tag, so it is discouraged to use Budou for body paragraphs.

As of October 2016, the Cloud Natural Language API supports English, Spanish, and Japanese, and Budou currently only supports Japanese. Support for other Asian languages with line break issues, such as Chinese and Thai, will be added as the API adds support.

Any comments and suggestions are welcome. You can find us on GitHub.

By Shuhei Iitsuka, UX Engineer

Which languages convey the most information in the least space? Introducing the Unimorph dataset.

Several years ago a science journalist asked me which languages could pack the most information into a 140-character Tweet. Because Twitter defines a character roughly as a single Unicode code point, this turns out to be an easy question to answer. Chinese almost certainly rates as the most “compact” language from that point of view because a single Chinese character represents a whole morpheme (in linguist terminology, a minimal unit of meaning) whereas an English letter only represents a part of a morpheme. The Chinese equivalent of I don’t eat meat, which in English takes 16 characters including spaces is 我不吃肉, which takes just four.

But this question relates to a broader question that as a linguist I have often been asked: which languages are the most “efficient” at conveying information? Or, which languages can convey the same information in the smallest amount of space? Untethered by the idiosyncrasies of Twitter, this question becomes quite difficult to answer. What do you mean by “space”? Number of characters? Number of bytes? Number of syllables? Each of these has its own problems. And perhaps more crucially, what do you mean by “information”? The Shannon notion of information does not straightforwardly apply here.

A group of us at Google set out to answer this question, or at least to provide the form that an answer would have to take. We had the resources and experience needed to annotate data in multiple languages, and we were able to divert some of those resources to this task. The results were published in a paper presented at the 2014 International Conference on Language Resources and Evaluation in Reykjavík, Iceland.

We are now releasing the data on GitHub. The data consist of 85 sentences typical of the kinds of sentences generated by Google Now, translated into eight typologically diverse languages: English, French, Italian, German, Russian, Arabic, Korean, Chinese, which include some highly inflected and uninflected languages, and various types of morphology including inflectional and agglutinative. The data were annotated by one to three annotators depending on the language, with morphological information, counts of the marked features and other information. The main data file is in HTML, color coded by language, which makes it easy to browse but also easy to extract into other formats.

Since the basic information conveyed by each sentence can be assumed to be the same across languages, the main focus of the research was on the additional information that each language marks, and cannot avoid marking. For example, the English sentence:

Use my location for the search results and other services.

has the French translation:

Utilisez ma position pour les résultats de recherche et d'autres services.

The verb ending -ez, in boldface above marks “addressee respect”, a bit of information that is missing from the English original.  One could have used a different ending on the French verb, but then that would not avoid this bit of information—it would be choosing to mark lack of respect, or familiarity with the addressee.

In the paper we tried various ways of measuring the differing information content of the languages relative to various definitions of “space”. Considering all the factors together, we concluded that the languages that conveyed the most information in a given amount of space were highly inflected languages like Russian, with uninflected languages like Chinese actually being the “least efficient” at conveying information.

We don’t expect this to be the final answer, which is why we are releasing the data as open source in the hopes that others will find it useful and maybe can even extend it to more sentences or a wider variety of languages. Ultimately though, any answer to the question of which languages convey the most information in the smallest amount of space must seriously address what is meant by “information”, and must pay heed to the famous maxim by the Russian linguist Roman Jakobson (1959) that “languages differ essentially in what they must convey and not in what they may convey.”

By Richard Sproat, Research Scientist