Hi guys.
I have detected a problem in the Web Console which, if I select the language in English:
And I can see the contents of “Firewall → Firewall groups → Location groups”:
However, if I switch to Spanish, the following appears:
Is this happening to anyone else, or is it just me?
Best regards and thanks.
Hola Roberto,
Yo uso la web de administración en español y no tengo ningún problema. He cambiado a inglés y vuelto a español, y todo funciona correctamente.
Saludos.
Hi,
I’m using the spanish GUI without problems. I’ve switched to the english version and switched back to the spanish one and everything works fine.
Regards.
Hi Roberto. With CU195 Testing I also find the same effect.
@binabik didn’t see it as it is not occurring with CU194.
Normally when a page does not complete then I would expect some error message to be in the /var/log/httpd/error_log file but I have found nothing.
I will have a look through the changes made in CU195 Testing to see if I can find anything and try and see if I can find what is occurring on that page as well from the browser.
I think it would be worth raising a bug for this.
Hi @roberto
I noted that there was an update of the Spanish language file in CU195 Testing.
I changed the es.pl file back to the version that was in CU194 and the problem no longer occurs. So there is something peculiar affecting that Location Groups cgi page when using the Spanish changes you provided.
I noted that some of the changes were related to changing
Grupos de ubicación
to
Grupos de ubicación
I need to look and see if there is some cgi code that is repsonding to the & or the ; in the translation string.
I will do some testing to see if I can find which part is triggering the problem.
I think I suspect that I have found the reason for the issue.
When you select the action Grupos de ubicación in the cgi html code it gets the text as shown above, ie with the character ó.
However there is then a series of if statements where it checks if that action equals the text in the language string. However as that is not html code but perl string checking the code ends up comparing
Grupos de ubicación with Grupos de ubicación
and so they don’t match and it comes to the end of the whole if string and nothing has matched and so it just stops.
This issue will occur whenever any string comparison is done in the fwhosts.cgi page and also in any other WUI page that is doing a string comparison between a value obtained via an html action and the string in the language file.
Why did you change the ó to ó because when I use the Spanish language file from CU194 the ó is shown correctly there and the string comparison will work because the value from the html action is the same as the language string.
No need to raise a bug report on this.
Using the actual acute o character in the language wording causes the code to work again.
So I am creating a patch to change all the & code changes to the actual characters with their diacritical accents.
I think this is easier than reverting your Spanish language patch as then all the WireGuard additions would be lost.
Du bist eine maschine!!! 
Thanks for the prompt response. I also looked at the log you mentioned, but I didn’t see anything and didn’t know where to look next.
Thanks for the prompt resolution.
Greetings from Spain.
Hi again,
I did it like this to avoid this:
Since I have no programming skills, I don’t know how to write it, and I thought it would be in HTML with the &xacute; and things like that.
In my next updates, I’ll respect what’s already there without modifying what’s already established.
Thanks for everything.
So I had a look on my CU194 system with Spanish and I don’t see what you see. Mine looks like:-
I will try and see if I can figure out what is causing that symbol to be shown.
There must be something different in your setup to mine that is causing that.
Looking that character up it might be getting shown because the font type you have selected for your browser is not capable of showing the character involved.
I am using Firefox and I have the default font selected which is DejaVu Sans at a size of 16 and that is working for me.
Are you using Firefox and what font type do you have selected?
The encoding for the html page on your browser should be set to utf-8.
You can find out what is set by being on the page in question and then on your Firefox menu choose Tools - Page Info.
This is what I get.
Okay, that is good and means that the WUI cgi page is sending the correct information to the browser on what character set should be used.
What I am less sure about is what could be making the browser not recognise those characters.
I have tried a whole range of fonts that are available on my Browser and all of them showed the correct accents on all the characters.
The only thing I have seen mentioned is that sometimes this has been experienced when something went wrong and it then stays in place because of the cache.
You could try clearing the cache on your browser or open the IPFire WUI in a Private Window as that always starts with an empty cache.
I don’t know if this will work or not as so far I have been unable to reproduce the white question mark in a black diamond on the IPFire WUI page. However, probably worth trying in a new Private Window as that will use a fresh empty cache and leave your existing cache as it is.
Thanks, Adolf.
With the es.pl file you attached in the other thread, all the problems have been resolved, and now everything looks perfect.
So, everything’s fine, thanks to you.
Best regards, and thanks for your efforts.
