Change the interface for user dictionary multiple locales.

The user dictionary interface now works the following way:
* Locale gathering
- The current locale is always considered as present, even if
there are no words for it in the user dictionary.
- Any locale for which at least one word is registered is
considered present.
- A null locale is considered a valid locale meaning "all
languages".
- If no words are present at all, since the current locale is
always considered present, the system will consider there is
exactly one locale present - and allow editing this user
dictionary.

* Options display
- If only one locale is present, the interface is the same as
for Honeycomb: display a "User dictionary" PreferenceScreen
that brings up the dictionary editor interface.
- If there are several locales present, then the user
dictionary option will jump to a screen that will display a
list of available locales.

* Word insertion
- Inserting a word will always use the locale of the currently
displayed dictionary. If it is the "all languages" null
pseudo-locale, that will still hold and the word will be added
to this pseudo-locale.

It is worthy to note that the "All languages" locale is only
accessible if for some reason there are already words with a
null locale in the database before this is installed. For
example, if an application has inserted some words that way,
or if the user inserted words with a previous version of the
settings application.
On a freshly flashed device, barring the use of third-party
application that would add such words, it is not possible to
access the "all languages" locale any more because there is
no interface to do it, though it works if such words are
inside.

Bug: 3479738
Change-Id: Iba323e5aeb3f4f575896903a4e8bef6ffb3ea306
This commit is contained in:
Jean Chalard
2011-05-12 15:06:16 +09:00
parent 309f385794
commit 71ad1f4e3e
6 changed files with 233 additions and 73 deletions

View File

@@ -36,8 +36,10 @@ import android.telephony.TelephonyManager;
import android.text.TextUtils;
import java.net.InetAddress;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;
import java.util.Locale;
public class Utils {
@@ -308,4 +310,24 @@ public class Utils {
}
return addresses;
}
public static Locale createLocaleFromString(String localeStr) {
// TODO: is there a better way to actually construct a locale that will match?
// The main problem is, on top of Java specs, locale.toString() and
// new Locale(locale.toString()).toString() do not return equal() strings in
// many cases, because the constructor takes the only string as the language
// code. So : new Locale("en", "US").toString() => "en_US"
// And : new Locale("en_US").toString() => "en_us"
if (null == localeStr)
return Locale.getDefault();
String[] brokenDownLocale = localeStr.split("_", 3);
// split may not return a 0-length array.
if (1 == brokenDownLocale.length) {
return new Locale(brokenDownLocale[0]);
} else if (2 == brokenDownLocale.length) {
return new Locale(brokenDownLocale[0], brokenDownLocale[1]);
} else {
return new Locale(brokenDownLocale[0], brokenDownLocale[1], brokenDownLocale[2]);
}
}
}