summaryrefslogtreecommitdiffstats
path: root/base/i18n/rtl.cc
Commit message (Collapse)AuthorAgeFilesLines
* Check string and UI direction in GetDisplayStringInLTRDirectionality, etc.msw@chromium.org2012-09-131-5/+8
| | | | | | | | | | | | | | | | | Continue always wrapping the string in RTL UI. (in case it's appended to an RTL string later, etc.) Additionally wrap strings with RTL first strong characters in LTR UI. (previously, text inherited UI base direction, now it uses the first strong char) Add, expand upon, and cleanup unit tests. BUG=144541 TEST=Download shelf (and other UI) file paths are shown as LTR (without stray rendered glyphs or other regressions). Review URL: https://chromiumcodereview.appspot.com/10910128 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156459 0039d316-1c4b-4281-b951-d872f2087c98
* Remove TOOLKIT_USES_GTK and consolidate it into TOOLKIT_GTKoshima@chromium.org2012-04-051-10/+1
| | | | | | | | | | | Add gtk dependency to base.gyp for android host_os="linux" case BUG=none TEST=none Review URL: https://chromiumcodereview.appspot.com/9969080 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130784 0039d316-1c4b-4281-b951-d872f2087c98
* ntp4: fix app title directionalityestade@chromium.org2011-10-041-2/+36
| | | | | | | | | BUG=93339 TEST=manual Review URL: http://codereview.chromium.org/7779024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@103904 0039d316-1c4b-4281-b951-d872f2087c98
* Upstream android i18n changemichaelbai@google.com2011-08-291-5/+5
| | | | | | | | | BUG= TEST= Review URL: http://codereview.chromium.org/7741032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@98638 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the loading of ca@valencia.pak, which is available intony@chromium.org2011-06-061-1/+9
| | | | | | | | | | | | | Ubuntu's chromium-browser package. We weren't handling language variant at all. BUG=83397 TEST=Covered by new unittests. Review URL: http://codereview.chromium.org/7086017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@88043 0039d316-1c4b-4281-b951-d872f2087c98
* wstring: remove wstring functions from base/i18n/rtl.hevan@chromium.org2011-04-251-51/+1
| | | | | | | | | | And update callers. BUG=23581 Review URL: http://codereview.chromium.org/6883140 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@82924 0039d316-1c4b-4281-b951-d872f2087c98
* Fix extension install UI for extensions with RTL Names.jeremy@chromium.org2010-12-121-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a version of AdjustStringForLocaleDirection() that handles the quirks of GTK/OSX label autodirectionality. Comment from the CL: // On OS X & GTK the directionality of a label is determined by the first // strongly directional character. // However, we want to make sure that in an LTR-language UI all strings are // left aligned and vice versa. // A problem can arise if we display a string which starts with user input. // User input may be the opposite directionality and so the whole string will // be displayed in the opposite directionality, e.g. if we want to display in // an LTR UI [such as US English]: // // EMAN_NOISNETXE is now installed. // // Since EXTENSION_NAME begins with a strong RTL char, the label's // directionality will be set to RTL and the string will be displayed visually // as: // // .is now installed EMAN_NOISNETXE // // In order to solve this issue, we prepend an LRM to the string which is a // strongly directional LTR char. // We also append an LRM at the end which ensures that we're in an LTR // context. // Unlike Windows, Linux and OS X can correctly display RTL glyphs out of the // box so there is no issue with displaying zero-width bidi control characters // on any system. Thus no need for the !IsRTL() check here. BUG=63303 TEST=1. Try scenario described in bug. 2. Make sure there areno regressions displaying RTL strings in LTR UI and vice versa on OS X. Review URL: http://codereview.chromium.org/5291009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68967 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup AdjustStringForLocaleDirection() to modify input parameter in place.jeremy@chromium.org2010-11-241-12/+9
| | | | | | | | | | | As described in the bug, the current behavior is confusing and bug-prone. BUG=47194 TEST=Check that there are no visible regressions in RTL and LTR language UIs on Linux & Windows. Review URL: http://codereview.chromium.org/5154009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67237 0039d316-1c4b-4281-b951-d872f2087c98
* The UI language rather than the locale is now used to pick Chrome's language ↵grt@chromium.org2010-11-161-16/+0
| | | | | | | | | | | | | | | on Windows. (Also fixed some unrelated lint errors.) With this change, l10n_util::GetApplicationLocale first checks for an override of the "configured locale" (in base::i18n) containing the list of preferred Windows UI languages. The browser triggers an override early in startup before the ApplicationLocale is determined. In effect, the browser no longer uses ICU on Windows for language detection. (This locale override mechanism is borrowed from the OS X port.) Changes in Chrome Frame are largely a refactor, as some Win32 code in there has been moved into base/win. Also cleaned up language selection in installer_util so that the proper language is chosen for the EULA, installer messages, and shortcuts. In so doing, replaced hand-crafted lists of supported languages with either auto-generated lists (static consts) or logic so that the addition of translations in the future doesn't require code motion (that being said, there may be reason to update the alias and/or wildcard tables in language_selector.cc). In so doing, this change unlocks Amharic, Farsi, and Swahili translations for installer messages and shortcuts. BUG=39986,40496,26470 TEST=New MUI/Win32 calls are tested in base/win/i18n_unittest.cc. To test the overall functionality, uninstall Chrome, remove intl.app_locale user pref, switch to a supported display language (via the "Keyboards and Languages" tab of Win7's "Regional and Language" control panel, and install with { "distribution": { "require_eula": true } } in master_preferences (via -installerdata arg to setup.exe). If all goes well, both EULA and outer frame are in the same language as Windows. Also, from gwilson: "Install system-level Chrome in audit mode on a new machine, then go through the out-of-box-experience, select a language, and the in -product EULA (triggered by "require_eula" : true) and Chrome's UI should be in the language that the user selected." Review URL: http://codereview.chromium.org/4139010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66275 0039d316-1c4b-4281-b951-d872f2087c98
* Use GLib to parse environment variables to determine the default locale.jshin@chromium.org2010-10-301-8/+41
| | | | | | | | | | | | | | | | | | | | | | Switch to using GLib, instead of having a Chromium specific implementation, for parsing environment variables for language preferences for all POSIX systems that use GTK+. If we have a non-GTK port in the future, we have to resurrect our custom code. This will guarantee that UI language selection in Chromium works just like for all other GTK+ applications, and simplify the code. While doing this, also do some cleaning-up of the language preferences code and add a test case to verify that the prioritization is done correctly. Original CL by Fredrik Roubert at http://codereview.chromium.org/2901004/show BUG=NONE TEST=app_unittest with "--gtest_filter=L10nUt*.*Loc*" passes. Review URL: http://codereview.chromium.org/4217004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64524 0039d316-1c4b-4281-b951-d872f2087c98
* Convert GetDisplayStringInLTRDirectionality from wstring to string16.tony@chromium.org2010-08-181-4/+6
| | | | | | | | BUG=23581 Review URL: http://codereview.chromium.org/3108027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56535 0039d316-1c4b-4281-b951-d872f2087c98
* [chromeos]Set GtkWidget's default direction correctly.suzhe@chromium.org2010-07-021-1/+10
| | | | | | | | | BUG=41558 TEST=Login ChromeOS with a RTL language, the text in the omnibox should be right aligned. Review URL: http://codereview.chromium.org/2833052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@51471 0039d316-1c4b-4281-b951-d872f2087c98
* Replace wstring with string16 in history. The only time wstring is used now ↵brettw@chromium.org2010-06-231-13/+54
| | | | | | | | | | | | in history is for bookmark-related stuff (the bookmarks system is still wstring-based). The substantial change here is in RTL to make a string16 variant of the functions and in changing the WordIterator to use string16 (this cleaned up some weird utf-32 code). TEST=none BUG=none Review URL: http://codereview.chromium.org/2808017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50597 0039d316-1c4b-4281-b951-d872f2087c98
* This CL fixes issue 42867 - "OK" button disabled on "Edit Exception" dialog boxxji@chromium.org2010-05-071-1/+16
| | | | | | | | | | | | | | | | | | | | when URL is modified in non-empty input field - RTL In RTL chrome in windows, the text get from "Pattern" text field is wrapped with LRE/POP, which makes the pattern invalid. Trim explicit bidi control characters off in NativeTextfieldWin::GetText(). BUG=http://crbug.com/42867 TEST= 1. Launch Chrome with RTL language UI 2. click Wrench => Options => Under the Hood => Content settings => Exceptions => Edit... 3. modify an existing url on the Pattern field. The "OK" button should not be grayed out. Review URL: http://codereview.chromium.org/1703026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46751 0039d316-1c4b-4281-b951-d872f2087c98
* Small cleanups/style fixes. Simplifies RTL functions slightly.pkasting@chromium.org2010-05-051-15/+17
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/1932006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46419 0039d316-1c4b-4281-b951-d872f2087c98
* Move RTL related functions from app/l10n_util to base/i18n/rtlben@chromium.org2010-03-201-0/+228
TBR=darin BUG=none TEST=none Review URL: http://codereview.chromium.org/1073005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42182 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-01 10:01:15 +0000