Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Localized download folder name renders downloaded programs unusable/uninstallable
6 views
Skip to first unread message
Eduardo Trápani
Mar 5, 2012, 7:39:32 AM3/5/12
to dev-l10n
Hi,
I just filed Bug 732920[1]. The problem was first detected in the
Esperanto localization but I checked and it happens with other
localizations as well (at least: ru, th) and I guess that will happen
with most locales using a non iso-8859-1 text for that folder.
How can we fix it? Just an idea: check at install time check that
downloadsFolder' in toolkit:downloads.properties can be read from. If
it is unreadable then we could either:
* have an additional property to used as an alternative, for example
the transliteration.
* if there is a way to 'discover' the default download folder name for
the host's locale, use that.
Any ideas? As localizers maybe the second option is the better, so we
don't have to deal with another string. I filed the bug under "shell
integration" but I wanted you people to know about it because it is
pretty nasty, the user had been struggling with the problem for some
hours, downloading the program many times. And it took me a while to
figure out what it was.
Eduardo.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=732920
I just filed Bug 732920[1]. The problem was first detected in the
Esperanto localization but I checked and it happens with other
localizations as well (at least: ru, th) and I guess that will happen
with most locales using a non iso-8859-1 text for that folder.
How can we fix it? Just an idea: check at install time check that
downloadsFolder' in toolkit:downloads.properties can be read from. If
it is unreadable then we could either:
* have an additional property to used as an alternative, for example
the transliteration.
* if there is a way to 'discover' the default download folder name for
the host's locale, use that.
Any ideas? As localizers maybe the second option is the better, so we
don't have to deal with another string. I filed the bug under "shell
integration" but I wanted you people to know about it because it is
pretty nasty, the user had been struggling with the problem for some
hours, downloading the program many times. And it took me a while to
figure out what it was.
Eduardo.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=732920
Rimas Kudelis
Mar 5, 2012, 9:05:07 AM3/5/12
to dev-...@lists.mozilla.org
VLC installer (NSIS-based, BTW) there and tried running it from there.
It worked fine.
Then I renamed the folder to "щврфшырвашфщыовыфщшво", and it did not. I
got "Error launching installer".
My conclusion is that this problem is much more likely to occur when the
name of your download folder contains symbols outside of the system's
non-unicode codepage, which shouldn't often be the case. So it's not
that bad, after all.
I think that whether ot not this should affect localization, depends on
how likely the users of that locale are to use an incompatible 8-bit
codepage. Maybe the situation is rather specific to Esperanto?
Now, I can't imagine why NSIS is still not unicode-aware, but I would
suggest to file this bug in their bugtracker too (if it's not filed
yet). In 2012, who needs Windows 98 compatibility anyway?
Rimas
Rimas Kudelis
Mar 5, 2012, 9:23:16 AM3/5/12
to
2012.03.05 16:05, Rimas Kudelis rašė:
> 2012.03.05 14:39, Eduardo Trápani rašė:
>> Hi,
>>
>> I just filed Bug 732920[1]. The problem was first detected in the
>> Esperanto localization but I checked and it happens with other
>> localizations as well (at least: ru, th) and I guess that will happen
>> with most locales using a non iso-8859-1 text for that folder.
Sorry, I didn't notice this sentence at first. :) It's not always
> 2012.03.05 14:39, Eduardo Trápani rašė:
>> Hi,
>>
>> I just filed Bug 732920[1]. The problem was first detected in the
>> Esperanto localization but I checked and it happens with other
>> localizations as well (at least: ru, th) and I guess that will happen
>> with most locales using a non iso-8859-1 text for that folder.
iso-8859-1 (more likely, it never is). It's the system codepage that
matters, which is cp1252 for Western Europe and US, cp1257 for me,
cp1251 for russians and so on.
>> How can we fix it? Just an idea: check at install time check that
>> downloadsFolder' in toolkit:downloads.properties can be read from. If
>> it is unreadable then we could either:
>>
>> * have an additional property to used as an alternative, for example
>> the transliteration.
>>
>> * if there is a way to 'discover' the default download folder name for
>> the host's locale, use that.
default Downloads folder in Vista and 7 by default. XP didn't have one,
at least initially, so in XP, Firefox uses name from its own locale instead.
Rimas
Eduardo Trápani
Mar 5, 2012, 10:16:09 AM3/5/12
to dev-l10n
> My conclusion is that this problem is much more likely to occur when the
> name of your download folder contains symbols outside of the system's
> non-unicode codepage, which shouldn't often be the case. So it's not
> that bad, after all.
What "is not that bad, after all" failing every now and then with not
> name of your download folder contains symbols outside of the system's
> non-unicode codepage, which shouldn't often be the case. So it's not
> that bad, after all.
clear indication of what happened? Going through the install process
without being able to detect the problem? Forcing users to use the same
language for the operating system and the browser?
> I think that whether ot not this should affect localization, depends on
> how likely the users of that locale are to use an incompatible 8-bit
> codepage. Maybe the situation is rather specific to Esperanto?
to Russian and Thai, it is not specific to one single localization
(actually I knew somebody would say just that so I took the time to test
other localizations). It is rather a mismatch between the Windows XP
locale and that of Firefox. And as we get more people involved that is
going to happen more often. Some people might be willing to use a
localized version of Firefox, but that does not mean they want (or even
can) have Windows XP in the same language!
My point is, Firefox is great, because I can use it in the language I
want, even if the operating system does not support it. We all expect
it to work. If that is not the case, users and localization teams
should be warned or a solution be found. At least that's what I think.
Eduardo.
Rimas Kudelis
Mar 5, 2012, 12:10:25 PM3/5/12
to
2012.03.05 17:16, Eduardo Trápani rašė:
>> My conclusion is that this problem is much more likely to occur when the
>> name of your download folder contains symbols outside of the system's
>> non-unicode codepage, which shouldn't often be the case. So it's not
>> that bad, after all.
>
> What "is not that bad, after all" failing every now and then with not
> clear indication of what happened? Going through the install process
> without being able to detect the problem? Forcing users to use the same
> language for the operating system and the browser?
>
>> I think that whether ot not this should affect localization, depends on
>> how likely the users of that locale are to use an incompatible 8-bit
>> codepage. Maybe the situation is rather specific to Esperanto?
>
> In case you missed it, I already stated in the bug that the same happens
> to Russian and Thai, it is not specific to one single localization
> (actually I knew somebody would say just that so I took the time to test
> other localizations). It is rather a mismatch between the Windows XP
> locale and that of Firefox.
Exactly. Which is why I don't think this would be a common case for
>> My conclusion is that this problem is much more likely to occur when the
>> name of your download folder contains symbols outside of the system's
>> non-unicode codepage, which shouldn't often be the case. So it's not
>> that bad, after all.
>
> What "is not that bad, after all" failing every now and then with not
> clear indication of what happened? Going through the install process
> without being able to detect the problem? Forcing users to use the same
> language for the operating system and the browser?
>
>> I think that whether ot not this should affect localization, depends on
>> how likely the users of that locale are to use an incompatible 8-bit
>> codepage. Maybe the situation is rather specific to Esperanto?
>
> In case you missed it, I already stated in the bug that the same happens
> to Russian and Thai, it is not specific to one single localization
> (actually I knew somebody would say just that so I took the time to test
> other localizations). It is rather a mismatch between the Windows XP
> locale and that of Firefox.
Russian or Thai users (although my assumptions are based on Russian
particularly). Regardless of the OS locale, I believe those users are
very likely to have the correct 8-bit codepage chosen, because otherwise
not just VLC's installer wouldn't work, but pretty much any localized
non-unicode application would break too.
> And as we get more people involved that is
> going to happen more often. Some people might be willing to use a
> localized version of Firefox, but that does not mean they want (or even
> can) have Windows XP in the same language!
good non-unicode codepage in the system preferences. Unless of course
Firefox is one of just few applications localized into their language,
and all of the localized apps they use are unicode-aware.
> My point is, Firefox is great, because I can use it in the language I
> want, even if the operating system does not support it. We all expect
> it to work. If that is not the case, users and localization teams
> should be warned or a solution be found. At least that's what I think.
hadn't been discovered and escalated before, I would be right. ;)
That doesn't stop us from having an L10n note above that string or
something similar. Or trying to come up with even better measures (e.g.
the warning dialog I suggested earlier).
Rimas
Eduardo Trápani
Mar 5, 2012, 1:47:52 PM3/5/12
to dev-l10n
>> My point is, Firefox is great, because I can use it in the language I
>> want, even if the operating system does not support it. We all expect
>> it to work. If that is not the case, users and localization teams
>> should be warned or a solution be found. At least that's what I think.
>
> I agree. I just don't think this problem is that severe, and assuming it
> hadn't been discovered and escalated before, I would be right. ;)
I agree is not severe. I filed as normal and I'm ready to drop it to
>> want, even if the operating system does not support it. We all expect
>> it to work. If that is not the case, users and localization teams
>> should be warned or a solution be found. At least that's what I think.
>
> I agree. I just don't think this problem is that severe, and assuming it
> hadn't been discovered and escalated before, I would be right. ;)
wishlist.
But about you being right because it has not been discovered ... I have
to disagree and you'll have to agree with me ;). You might want to
check this[1] from NSIS (cyrillic + workaround). Or better yet, please
check this[2] one, from a Romanian blog, on Mozilla Firefox, just a
couple of weeks old!! Exactly the same issue.
> That doesn't stop us from having an L10n note above that string or
> something similar. Or trying to come up with even better measures (e.g.
> the warning dialog I suggested earlier).
note above the string, should someone ever spot it, could help us
localizers know that it is a potential issue.
Eduardo.
[1] http://nsis.sourceforge.net/Talk:Why_do_I_get_NSIS_Error
[2]
http://www.tutorialepc.ro/nsis-error-error-launching-installer-remediere-problema-2.html
Rimas Kudelis
Mar 5, 2012, 2:30:21 PM3/5/12
to
2012.03.05 20:47, Eduardo Trápani rašė:
>>> My point is, Firefox is great, because I can use it in the language I
>>> want, even if the operating system does not support it. We all expect
>>> it to work. If that is not the case, users and localization teams
>>> should be warned or a solution be found. At least that's what I think.
>>
>> I agree. I just don't think this problem is that severe, and assuming it
>> hadn't been discovered and escalated before, I would be right. ;)
>
> I agree is not severe. I filed as normal and I'm ready to drop it to
> wishlist.
>
> But about you being right because it has not been discovered ... I have
> to disagree and you'll have to agree with me ;). You might want to
> check this[1] from NSIS (cyrillic + workaround). Or better yet, please
> check this[2] one, from a Romanian blog, on Mozilla Firefox, just a
> couple of weeks old!! Exactly the same issue.
>>> My point is, Firefox is great, because I can use it in the language I
>>> want, even if the operating system does not support it. We all expect
>>> it to work. If that is not the case, users and localization teams
>>> should be warned or a solution be found. At least that's what I think.
>>
>> I agree. I just don't think this problem is that severe, and assuming it
>> hadn't been discovered and escalated before, I would be right. ;)
>
> I agree is not severe. I filed as normal and I'm ready to drop it to
> wishlist.
>
> But about you being right because it has not been discovered ... I have
> to disagree and you'll have to agree with me ;). You might want to
> check this[1] from NSIS (cyrillic + workaround). Or better yet, please
> check this[2] one, from a Romanian blog, on Mozilla Firefox, just a
> couple of weeks old!! Exactly the same issue.
> [1] http://nsis.sourceforge.net/Talk:Why_do_I_get_NSIS_Error
> [2]
>
http://www.tutorialepc.ro/nsis-error-error-launching-installer-remediere-problema-2.html
You're right, and my assumption was incorrect. Shame on NSIS though, not
> [2]
>
http://www.tutorialepc.ro/nsis-error-error-launching-installer-remediere-problema-2.html
on us.
I'm lucky that my locale doesn't have non-ascii characters in the
translation of word "Download", but if it did, I don't think I would
consider invalidating that word just because some installers feel like
compatibility with Win9x is more important than compatibility with Win7.
It's just dumb.
I think it's NSIS who should be poked most about this. Also, bugs could
be filed for the projects using NSIS, to better distribute the pressure
on NSIS to fix this bug. :)
>> That doesn't stop us from having an L10n note above that string or
>> something similar. Or trying to come up with even better measures (e.g.
>> the warning dialog I suggested earlier).
>
> Yes, a warning dialog at install time might be a good solution. And the
> note above the string, should someone ever spot it, could help us
> localizers know that it is a potential issue.
because:
* The user might easily forget the warning message that was presented to
them during installation.
* The system's 8-bit codepage can be changed at any time.
* On one hand, "Downloads" folder issue does not affect all
localizations, only those that use non-ascii symbols in its name.
* On the other hand, this issue is not specific to the "Downloads"
folder. You can copy the file to C:\Users\Trápani\Desktop\, and I think
the problem will still manifest itself if your 8-bit codepage is e.g.
Russian.
Rimas
Rimas Kudelis
Mar 5, 2012, 2:51:44 PM3/5/12
to
right thing. Perhaps they could just be poked to default to require XP
as a minimum.
On the other hand, VLC's page states that they also require XP or
higher. It's probably worth filing a bug for them too, asking to use the
option documented in [3] when generating the installer. They would first
need to update the version of NSIS they are using though.
[3] http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.2.9
[4] http://nsis.sourceforge.net/Docs/Chapter1.html#1.4
Rimas
Mark Tyndall
Mar 7, 2012, 6:49:04 AM3/7/12
to
On 05/03/2012 12:39, Eduardo Trápani wrote:
>
[...]
is referred to with the constant FOLDERID_Downloads (there are others [2]).
Known Folders replaces the older CSIDL system for enumerating shell
folders. I don't *think* that there was a "Downloads" folder in the
CSIDL system.
Mark.
[1] http://msdn.microsoft.com/en-us/library/bb776911%28v=vs.85%29.aspx
[2] msdn.microsoft.com/en-us/library/dd378457(v=vs.85).aspx
>
[...]
> * if there is a way to 'discover' the default download folder name for
> the host's locale, use that.
Using the Vista-or-newer Known Folders [1] system, the Downloads folder
> the host's locale, use that.
is referred to with the constant FOLDERID_Downloads (there are others [2]).
Known Folders replaces the older CSIDL system for enumerating shell
folders. I don't *think* that there was a "Downloads" folder in the
CSIDL system.
Mark.
[1] http://msdn.microsoft.com/en-us/library/bb776911%28v=vs.85%29.aspx
[2] msdn.microsoft.com/en-us/library/dd378457(v=vs.85).aspx
0 new messages