Localized Chromoting Host on Mac and Linux.

remoting/base/resources_win.cc

+// Copyright 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "remoting/base/resources.h"
+
+namespace remoting {
+
+bool LoadResources(const std::string& pref_locale) {
+  // Do nothing since .pak files are not used on Windows.
+  return false;

[Sergey Ulanov, 2013/07/25 18:40:57]

I think it would be more logical to return true from here - we can assume that
resources are loaded from the start, but returning false from here indicates
that they are not. 
In either case mac/linux implementation always return true, so I wonder if we
need to return anything here at all (i.e. maybe declare the function result as
void).

[alexeypa (please no reviews), 2013/07/25 18:48:03]

That is exactly why this return value is needed. If it is false, functions like
l10n_util::GetStringUTF8() may not be called. In other words, |false| means that
Chrome-style localization is not available.

[Sergey Ulanov, 2013/07/26 17:58:25]

I see. Sorry, I mistakenly assumed that l10n_util will still work (pulling
strings from .rc). If it doesn't then it will break cross-platform code that
needs localized strings - It's probably not a problem right now, but may become
one in the future. Will it be possible to avoid ifdefs in that case?

[alexeypa (please no reviews), 2013/07/26 18:55:01]

This is the price for not having dependency on icudt.dll. Now there is a good
chance that we may need to add this dependency because of changes in chromium
code outside of remoting. If this ever happens that plan is to add icudt.dll and
.pak files to the installation and make LoadResources to initialize the resourse
bundle just like Linux does.

+}
+
+void UnloadResources() {
+}
+
+}  // namespace remoting