Generate <p dir="rtl"> instead of <p dir=rtl>. The form with the quotes
is cleaner and will reduce warnings in apps that consume the output.
Change-Id: Ic9879c8c882c42079598b741e897a24415d96374
* commit 'b4a80baaff113f0f9ba357bfbd5dc0cb85dc8987':
Fix bug #7282594 EditText does not allow to move the cursor when typing RTL text and if gravity is set to LEFT
* commit '5e5169b0d0d51e042a79ca32d2825fc5f4a25531':
Fix bug #7282594 EditText does not allow to move the cursor when typing RTL text and if gravity is set to LEFT
* commit '33c36895a294c7b731fd59017a7ea0f06ac2a356':
Fix bug #7282594 EditText does not allow to move the cursor when typing RTL text and if gravity is set to LEFT
* commit 'ce14f2176028108b649b3b068ac1275b81287b21':
Fix formatDateRange month names for Farsi.
Use localized digits for Time formatting.
Use proper digits in formatElapsedTime and format3339
* commit '3d5be42eaa35914d9b37fe052fa7222dc1992dc0':
Fix formatDateRange month names for Farsi.
Use localized digits for Time formatting.
Use proper digits in formatElapsedTime and format3339
This fixes the digits in places like Settings' data usage page
and Calendar's drop-down, for languages such as Arabic.
Bug: 6811327
Change-Id: I2dafcc342e3279937735697b3748b47fdfc8e691
Use getZeroDigit() instead of a hard-coded '0' for formatting times using
formatElapsedTime, so locales with different digits like Arabic and Persian
could display the elapsed time properly. This is visible in Settings' list
of running apps.
Also changed android.text.format.Time's format3339 method to always use ASCII
digits, irrespective of the locale.
Change-Id: I731c96c21b3712ec347d9526e4ec3fe884dec276
This brings DateUtils and Time in sync with bionic, icu, WebKit,
DateFormatSymbols, Formatter, and SimpleDateFormat. And specifically
means that DateUtils now knows how to say "AM" and "PM" in Japanese.
Bug: 6719054
(cherry-pick of b12b61a88a029730b1f2b006ff914c9c719f3942.)
Conflicts:
core/res/res/values/public.xml
Change-Id: Ic1a811621a0ec338abd77458ac2046577f87c1e4
Applications using these fields and methods are just asking for i18n bugs.
Also @deprecate two int[]s that were never meant to be public.
Change-Id: I29b3a1c0c663fe344d2567df6ed3bb537270b3b7
Before the suggestion selection were notified only when they were added by
an IME. This CL relaxes this constrain, and the suggestion are notified
even if they are added by an application.
If the context is null and the package name of the apk cannot be determined,
the suggestion are notified using the old method via the Input Method Manager.
This is required to keep the backward compatibility.
Bug: 6905960
Change-Id: If225ef27cded386809fbd899e34e32aced4e0473
All variations of getRelativeTimeSpanString() now properly handle dates
that are in the future. Prior, the version used by
getRelativeDateTimeString() would occasionally show the time instead of
a date when the future date was the same weekday as the current weekday.
This resulted in the time output being duplicated, eg.: "11:23, 11:23"
Change-Id: If20972a6942cce792fa233437f94dedfb71379f3
Signed-off-by: Steve Pomeroy <steve@staticfree.info>
We were doing line breaks after punctuation as long as they weren't
surrounded by digits. This is a misinterpretation of the Unicode line
breaking algorithm. Punctuation (class IS) is not hugely different than
the default classes (NU and AL) - there are breaks after punctuation
that are allowed (for example, followed by an open parenthesis), but
we're not implementing the algorithm with anything near that level of
fidelity.
The long term fix is to really implement the algorithm. In the shorter
term, the easiest thing to do is to remove the special case altogether.
Change-Id: Ic4dc3216c2a4191fbb7cfa06e9dc038d1a56398c
Cherry-pick of I7f1b0d49a2ece957a7b9b5d65d48385bf2c2a668 from master.
I've also provided TextView.setTextLocale() for use in single-language
TextViews.
Change-Id: I5692859bfd2aafc284172454d943afc250b22535
