Issue 3501 - use hardcoded value until there is a real error message

[Eric, 2016-01-13 15:14:13]

https://codereview.adblockplus.org/29333426/diff/29333427/src/plugin/PluginCl...
File src/plugin/PluginClass.cpp (right):

https://codereview.adblockplus.org/29333426/diff/29333427/src/plugin/PluginCl...
src/plugin/PluginClass.cpp:1628: ReplaceString(errorText , L"?1?", L"Unknown
error");
I'm uncomfortable with putting an English phrase into a translated UI element.
The empty string would be better, which we could do with L"\"\"" as the
substitution string.

I'd actually prefer to change the text in "update-error-text" to remove the
substitution entirely, but that means more translation work. Using the empty
string would be acceptable.

Are the error text strings to be presented to the user already present as
translated strings?

[sergei, 2016-01-13 16:00:57]

It's much better to discuss such things in issue tracker.

On 2016/01/13 15:14:13, Eric wrote:
> I'd actually prefer to change the text in "update-error-text" to remove the
> substitution entirely, but that means more translation work. Using the empty
> string would be acceptable.
Yes, it means more translation work. I don't know what is a plan. If we plan to
deliver the actual error message somehow to the user then it seems better to
keep the current string and use it with some stub because it will look strange
to firstly drop this part and ask to translate, and then restore it and ask to
translate again. If there is no plan to show it to the user then I would just
drop it. May be it's enough to write it or something meaningful for us into some
log file and ask the user to send it to us if he cannot figure out the trouble.

...
> Are the error text strings to be presented to the user already present as
> translated strings?
It depends where we will obtain it from.

If it comes from MS Windows then it depends what we are passing to the function
which converts the error code into the error message. It can also depend on the
current application locale (apparently the locale of the engine in our case,
which, I think, should be "C" application-wise, but now it seems a current user
locale). As I see, if it comes from some exception then it won't be translated.
I actually don't remember any translation of any error messages of such level in
'adblockplus' project, so if it comes from 'adblockplus' then it might be an
English message.

In addition I personally cannot recall any place where we obtain a message
description of an error.

> I'm uncomfortable with putting an English phrase into a translated UI element.
> The empty string would be better, which we could do with L"\"\"" as the
> substitution string.
IMO, from the UX point of view it's better to show some error message even in
Chinese than an empty string because the empty string looks like a bug in our
software which always makes negative impression.

[Eric, 2016-01-13 16:38:05]

On 2016/01/13 16:00:57, sergei wrote:
> It's much better to discuss such things in issue tracker.

Actions speak louder than words. You replied in the review tool.

> it will look strange
> to firstly drop this part and ask to translate, and then restore it and ask to
> translate again. 

No need for a second translation. We can simply revert to the present version.

And the translation isn't hard, because it's dropping a second sentence. I
suspect we could do it ourselves just by looking for the period character.

> If there is no plan to show it to the user then I would just
> drop it. 

We make and propose the plan. Deferring to a plan that doesn't exist before we
create is a recipe for stagnation.

> May be it's enough to write it or something meaningful for us into some
> log file and ask the user to send it to us if he cannot figure out the
trouble.

I was heading down that direction looking into this earlier. If the messages
generated are really meant for debugging, we shouldn't be showing them to users
at all.

> > Are the error text strings to be presented to the user already present as
> > translated strings?
> It depends where we will obtain it from.

I see you did not trace out where the messages came from. I just did.

These messages come from the core ABP code. Specifically, it's the value of
parameter 0 in the callback function 'FilterEngine::UpdateCheckDone'. This winds
up as the argument to engine function UpdateCallback(), which uses an
application-specific windows message to communicate back with the plugin. (I
recall complaining that this would cause us problems, and here we are.) At
present, that message does not contain a copy of the error message. Indeed, it
doesn't contain anything but the message-id; it has zero for 'wParam' and
'lParam'.

I did not read the JavaScript of the core to see how the messages are generated
or whether they are localized. I'll leave that to you if you want to delve in
that far.

> IMO, from the UX point of view it's better to show some error message even in
> Chinese than an empty string because the empty string looks like a bug in our
> software which always makes negative impression.

Personally, I think it looks worse to see an untranslated string in a message
that's supposed to be localized.

Our options (so far) look like this:
- Change the error text to avoid substitution entirely.
- Use a fixed string
  - Use "". Sergei is against this.
  - Use "Unknown error". I am against this.
- Use the string provided by the ABP core. If it's not localized, it's no worse
than every other version of ABP. This mechanism means passing a string in a
window message across a process boundary.

[Oleksandr, 2016-01-22 12:37:45]

As Eric wrote, our options are:
- Change the error text to avoid substitution entirely.

We may want to display the error text in future, so I don't think we should do
this.

- Use a fixed string
  - Use "". Sergei is against this.

I am against this as well. For example the English message would be:
"There was an error while checking for an update of Adblock Plus. The error text
was: ?1?". In this case "The error text was: _blank_" is more confusing then
undescriptive error text, I think. A user may expect to have undecipherable
error text more then a blank space, I think.

  - Use "Unknown error". I am against this.

- Use the string provided by the ABP core. If it's not localized, it's no worse
than every other version of ABP. This mechanism means passing a string in a
window message across a process boundary.

I don't think there's any argument that this is the best option. This changeset
just fixes the error message until the real error is pulled. 

One more option we have is to use one of the already translated strings. For
example "install-error-text" might work: "An error occurred while updating
Adblock Plus.". However it is no more descriptive then an "Unknown error" in my
optinion, so I'd just stick with that.