summaryrefslogtreecommitdiffstats
path: root/chrome/browser/extensions/extension_install_ui.cc
diff options
context:
space:
mode:
authorjeremy@chromium.org <jeremy@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-12-12 14:33:27 +0000
committerjeremy@chromium.org <jeremy@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-12-12 14:33:27 +0000
commit9c0b6647367bdc43549a00d1b6678820ed2dc54a (patch)
treea23e629a9bb3c4a9167ae25e59050a671a8ef1c6 /chrome/browser/extensions/extension_install_ui.cc
parent9507403c64711e7fe6b6112668f3a8bea69481a0 (diff)
downloadchromium_src-9c0b6647367bdc43549a00d1b6678820ed2dc54a.zip
chromium_src-9c0b6647367bdc43549a00d1b6678820ed2dc54a.tar.gz
chromium_src-9c0b6647367bdc43549a00d1b6678820ed2dc54a.tar.bz2
Fix extension install UI for extensions with RTL Names.
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
Diffstat (limited to 'chrome/browser/extensions/extension_install_ui.cc')
-rw-r--r--chrome/browser/extensions/extension_install_ui.cc5
1 files changed, 4 insertions, 1 deletions
diff --git a/chrome/browser/extensions/extension_install_ui.cc b/chrome/browser/extensions/extension_install_ui.cc
index 180300a..313a21a 100644
--- a/chrome/browser/extensions/extension_install_ui.cc
+++ b/chrome/browser/extensions/extension_install_ui.cc
@@ -10,6 +10,7 @@
#include "app/resource_bundle.h"
#include "base/command_line.h"
#include "base/file_util.h"
+#include "base/i18n/rtl.h"
#include "base/string_number_conversions.h"
#include "base/string_util.h"
#include "base/utf_string_conversions.h"
@@ -289,9 +290,11 @@ void ExtensionInstallUI::ShowGenericExtensionInstalledInfoBar(
if (!tab_contents)
return;
+ string16 extension_name = UTF8ToUTF16(new_extension->name());
+ base::i18n::AdjustStringForLocaleDirection(&extension_name);
string16 msg =
l10n_util::GetStringFUTF16(IDS_EXTENSION_INSTALLED_HEADING,
- UTF8ToUTF16(new_extension->name())) +
+ extension_name) +
UTF8ToUTF16(" ") +
l10n_util::GetStringUTF16(IDS_EXTENSION_INSTALLED_MANAGE_INFO_MAC);
InfoBarDelegate* delegate = new SimpleAlertInfoBarDelegate(