Quote
roytam1
Quote
cdlvcdlv
There is a problem that was annoying me since long time about not seeing the history of downloads. I thought it was some config option I messed up and I was unable to find. Long story short, lately I ended finding that it was a bug that affected to Spanish language GUI (my native language) since KM 76. I explain it at:
http://kmeleonbrowser.org/forum/read.php?19,145700,146177#msg-146177
There were some others languages with the error but now downloads history is broken only in Spanish.
I would have opened a bug but the bug tracker allows versions just from 0.9 to 76b4 -- what, I think, makes no sense because the latest versions are actually the ones that need bug tracking (who's going to report or fix a bug for v0.9?).
that means Spanish language files needs updating, maybe other members can help on this field?
One bug fixed, another ones found.
I managed to find and fix the annoying "No hay descargas" error. (Though I don't know if the fix will imply some other problems.) I'll explain how I found it, first to document it and second to show that sometimes one can help even not being a programmer and without complex tools. I made the tests with the portable versions so it won't interfere with existing installations. I downloaded and unzip them and made the following test: running K-Meleon, downloading a .zip file (for example,
http://o.rthost.win/gpc/files1.rt/km76g-gestures-nogdip.7z but any other will do), opening downloads history (Ctrl-J) and checking the zip is shown. Then, swapping language from English to Spanish and verifying it's hidden (it reappears swapping back to English).
- v75.1 works fine.
- v76RC quickly open and closes the Save... window and doesn't download anything with default settings. You must set a download folder in Preferences/Browsing/File handling. But it has the bug that hides the downloads in Spanish locale.
- v76RC2 downloads the zip but it has also the bug.
- Goanna builds: just the same.
By the way, v76RC and later closes Options when choosing a new GUI language but 75.1 changes cleanly the localized strings without closing Preferences.
So, what is wrong with Spanish locale since 75.1? Comparing the es-ES folders inside locales with WinMerge shows that .dll files are the same in the 4 versions. Good thing, because that means that the error must be in text files... or the .jar, that contains text files and a folders structure inside. Comparing the text files with WinMerge doesn't seem to produce anything wrong. Then maybe the .jar file is the culprit. This is tricky because I tried to extract the es-ES.jar, recreate as .zip and rename it to .jar again and it didn't work. So the .jar must be generated by a specific tool. I searched about the subject but all the information about localization of Mozilla products that I found was outdated. I had to download Mozilla Translator for archive.org but when I ran it frankly I was not sure about what I was doing. Finally, it turned out that 7zip can update a file inside a .jar directly just dragging and dropping the new version inside the 7zip window when you navigate to the folder of the file inside the .jar.
There are many folders inside the .jar. I tried to find the wrong file at a rough guess to no avail till it occurred to me to copy it.jar to es-ES folder and rename it es-ES.jar... and downloads history worked. In order to find what file was wrong I deleted and replaced the contents of the file by halves with the folders of it.jar -- if the error persisted, then the replaced part was good but if the problem disappeared the replaced part contained the bad file.
In the end, the file that should be fixed happened to be browser\downloads\downloads.dtd inside es-ES.jar which, in retrospect, makes a lot of sense. This file lacks six lines compared with the Italian one. I added the lines, translated them, assigned accesskeys not used in the file and overwriting this fixed downloads.dtd in es-ES.jar the Spanish locale can see the files in the downloads list. Finally, I used the file from fr.jar as template because it is well-documented with comments (the Italian one is just the values so it's difficult to say if you are doing it right). This is the final browser\downloads\downloads.dtd
<!-- This Source Code Form is subject to the terms of the Mozilla Public
- License, v. 2.0. If a copy of the MPL was not distributed with this file,
- You can obtain one at http://mozilla.org/MPL/2.0/. -->
<!-- LOCALIZATION NOTE (downloads.title):
Used by screen readers to describe the Downloads Panel.
-->
<!ENTITY downloads.title "Descargas">
<!-- LOCALIZATION NOTE (downloadDetails.width):
Width of details for a Downloads Panel item (which directly influences the
width of the Downloads Panel) expressed using a CSS unit. The longest
labels that should fit in the item width are usually those of in-progress
downloads and those of blocked downloads.
A good rule of thumb is to try to determine the longest string possible
that an in-progress download could display, and use that value in ch
units.
For example, in English, a long string would be:
59 minutes, 59 seconds remaining - 1022 of 1023 KB
That's 50 characters, so we set the width at 50ch.
-->
<!ENTITY downloadDetails.width "50ch">
<!-- LOCALIZATION NOTE (downloadsSummary.minWidth2):
Minimum width for the main description of the downloads summary,
which is displayed at the bottom of the Downloads Panel if the
number of downloads exceeds the limit that the panel can display.
A good rule of thumb here is to look at the otherDownloads2 string
in downloads.properties, and make a reasonable estimate of its
maximum length. For English, this seems like a reasonable limit:
+ 999 other downloads
that's 21 characters, so we set the minimum width to 21ch.
-->
<!ENTITY downloadsSummary.minWidth2 "21ch">
<!ENTITY cmd.pause.label "Pausar">
<!ENTITY cmd.pause.accesskey "P">
<!ENTITY cmd.resume.label "Continuar">
<!ENTITY cmd.resume.accesskey "R">
<!ENTITY cmd.cancel.label "Cancelar">
<!ENTITY cmd.cancel.accesskey "C">
<!-- LOCALIZATION NOTE (cmd.show.label, cmd.show.accesskey, cmd.showMac.label,
cmd.showMac.accesskey):
The show and showMac commands are never shown together, thus they can share
the same access key (though the two access keys can also be different).
-->
<!ENTITY cmd.show.label "Abrir la carpeta que lo contiene">
<!ENTITY cmd.show.accesskey "b">
<!ENTITY cmd.showMac.label "Mostrar en Finder">
<!ENTITY cmd.showMac.accesskey "F">
<!ENTITY cmd.retry.label "Reintentar">
<!ENTITY cmd.goToDownloadPage.label "Ir a la página de la descarga">
<!ENTITY cmd.goToDownloadPage.accesskey "G">
<!ENTITY cmd.copyDownloadLink.label "Copiar enlace de la descarga">
<!ENTITY cmd.copyDownloadLink.accesskey "L">
<!ENTITY cmd.removeFromHistory.label "Eliminar del historial">
<!ENTITY cmd.removeFromHistory.accesskey "e">
<!ENTITY cmd.clearList.label "Limpiar lista">
<!ENTITY cmd.clearList.accesskey "a">
<!ENTITY cmd.clearDownloads.label "Limpiar descargas">
<!ENTITY cmd.clearDownloads.accesskey "D">
<!-- LOCALIZATION NOTE (cmd.unblock.label):
This command may be shown in the context menu, as a menu button item, or as
a text link when malware or potentially unwanted downloads are blocked.
Note: This string doesn't exist in the UI yet. See bug 1053890.
-->
<!ENTITY cmd.unblock.label "Desbloquear">
<!ENTITY cmd.unblock.accesskey "o">
<!-- LOCALIZATION NOTE (cmd.removeFile.label):
This command may be shown in the context menu or as a menu button label
when malware or potentially unwanted downloads are blocked.
Note: This string doesn't exist in the UI yet. See bug 1053890.
-->
<!ENTITY cmd.removeFile.label "Borrar archivo">
<!ENTITY cmd.removeFile.accesskey "h">
<!-- LOCALIZATION NOTE (blocked.label):
Shown as a tag before the file name for some types of blocked downloads.
Note: This string doesn't exist in the UI yet. See bug 1053890.
-->
<!ENTITY blocked.label "BLOQUEADO">
<!-- LOCALIZATION NOTE (learnMore.label):
Shown as a text link for some types of blocked downloads, for example
malware, when there is an associated explanation page on the Mozilla site.
Note: This string doesn't exist in the UI yet. See bug 1053890.
-->
<!ENTITY learnMore.label "Más información">
<!-- LOCALIZATION NOTE (downloadsHistory.label, downloadsHistory.accesskey):
This string is shown at the bottom of the Downloads Panel when all the
downloads fit in the available space, or when there are no downloads in
the panel at all.
-->
<!ENTITY downloadsHistory.label "Mostrar todas las descargas">
<!ENTITY downloadsHistory.accesskey "S">
<!ENTITY clearDownloadsButton.label "Limpiar descargas">
<!ENTITY clearDownloadsButton.tooltip "Limpia las descargas completas, canceladas y fallidas">
<!-- LOCALIZATION NOTE (downloadsListEmpty.label):
This string is shown when there are no items in the Downloads view.
-->
<!ENTITY downloadsListEmpty.label "No hay descargas.">
<!-- LOCALIZATION NOTE (downloadsPanelEmpty.label):
This string is shown when there are no items in the Downloads Panel.
-->
<!ENTITY downloadsPanelEmpty.label "No hay descargas en esta sesión.">
<!-- LOCALIZATION NOTE (downloadsListNoMatch.label):
This string is shown when some search terms are specified, but there are no
results in the Downloads view.
-->
<!ENTITY downloadsListNoMatch.label "No se encuentra ninguna descarga que concuerde.">
Please replace it inside es-ES.jar; if you prefer the fixed .jar, I can upload it where you like.
And, after fixing this I realized... All the versions from 76RC show ALL the downloads as "Failed" (be it or not) and therefore don't offer some options in contextual menu as "Open containing folder", for example. And this one seems to be a source code bug, what I think is out of my league.
So, to sum up: "No hay descargas" fixed but all the downloads appear as failed. And it would be nice to bring back the 75.1 behavior not closing Preferences window after switching locales, but this is less important, just informing.
Edited 3 time(s). Last edit at 05/25/2018 10:17AM by cdlvcdlv.