You are viewing the PKP Support Forum | PKP Home Wiki

Strange characters

Are you responsible for making OCS work -- installing, upgrading, migrating or troubleshooting? Do you think you've found a bug? Post in this forum.

Moderators: jmacgreg, michael, John

Forum rules
What to do if you have a technical problem with OCS:

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved. Please note that this FAQ is OJS-centric, but most issues are applicable to both platforms.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OCS Conference Support and Discussion subforum; if you have a development question, try the OCS Development subforum.

Strange characters

Postby jomorlo » Thu Nov 19, 2009 4:40 pm

Hi all,

look at this screenshot. Do you know why I am seeing this character "##"? How can I avoid it?

Imagen 1.png
Imagen 1.png (40.09 KiB) Viewed 423 times
Posts: 2
Joined: Thu Nov 19, 2009 4:37 pm

Re: Strange characters

Postby jamief » Fri Nov 20, 2009 1:44 am

These are marks indicating areas of your installation that have no translation in the local file for those headings.
They are typical in the Spanish version of OCS installations. There are some 1000-2000 untranslated words/phrases in the spanish OCS.
What OCS does, is if it cannot find a translation for a hard coded phrase, it reverts to the default (english) but puts it inside double ##

Note: There are many types of spanish. I only use the castillian example in this post, as an example only, and do not wish to offend the argentine version users, in their case, they would chose the appropriate locale.xml language file.

To solve this, I recommend one of the following: The first one less labour intensive, the third one more complete.
Solution 1

1. Open a copy of both the english and spanish local files in text editors (not word, but phpedit or wordpad.
2. Login to your site, and look for instances of those untranslated occurences.
3. Search for a portion (for example search: manager.timeline.sheduleEvents (dont search for the #s) of the text in your ENGLISH LOCAL FILE
4. Copy the entire LINE into your Spanish locale.xml file - near the top if you like, so you know which ones you have added;
<message key="manager.reviewFormElements.dropdownbox">Drop-down box</message>

and perform the translation of the Text, replacing the english with a spanish translation:
<message key="manager.reviewFormElements.dropdownbox">Cuadro Desplegable</message>

Sometimes the text strings not being translated are those from plugins that you have installed from 3rd parties that have never been translated.
If this is the case, then you should use the following process instead:
Solution 2
1.Go directly to the Plugin folder
2. Find the folder for the specific plugin, enter and go inside the locale folder of the plugin.
3. If you notice there is no folder for your language (in your case "es_ES") copy the en_En and rename it "es_ES" (Don't just rename it, becuase it is the default and you may cause problems down the road.)
4. Now go into the newly created es_ES folder and do this:

Change the meta data about the language file (around line 15);

<locale name="en_US" full_name="U.S. English">

with this:

<locale name="es_ES" full_name="España Castellano (España)">

Now go through line by line the english translations as above, remember you are only interested in Changing the last part: The text to be displayed.
Save the files and upload them to your site.

Solution 3
This is the official solution.
Go to setup and turn on the translation plugin (enable it.)
A new link will appear allowing you to go to a table for translations. The system does a scan of all your locale files and lets you know the state of them.
Follow the instructions that come with this process and you will soon be translating line by line each and every instance of untranslated text.
Of course this is the most complete way, but I choose not to do it for several reasons.

1. It might produce 2000 plus lines of code to be translated, the majority of which my site users will never encounter. (They being administration texts and not user texts)
2. It produces an enormous amount of redundancy and false positives. I know my site translates Hotel as Alojamiento, but the translation system seems to think not.
3. You aren't always aware of where you are in the files, and after all is done, you cannot back up your individual files. This is important because if you do a system wide update of your OCS installation, you will LOSE all your translation work, until you replace the locale.xml files. NOT KNOWING which files you edited can mean always rolling back 100% of your locale.xml files, causing further problems. By doing manual translations, I have a copy of each and every locale file I edited, so on an upgrade I can copy and paste any/all my work to the top of the generic local file REGARDLESS of where the error occured (in a plugin, template, etc.)

NOTE: One thing you can do, using the above solutions, is also ENTER into the Spanish locale files to CHANGE the current translation of your OCS. For example, I have removed ALL instances of Conferencia/Congreso and conferencias/congresos from my working installation. I don't believe that here in Spain, people refer to their conferences as Conferencias, but rather, use that word differently. Here it we have Congresos, Seminarios, etc. So I have removed some words. I have also tried to harmonize translations like alojamiento/hospedaje because I notice they are used interchangable throughout the platform.

i.e. you can particularlize your translation according to a set of standards you go by, rather than those of the translator of the original.

These solutions are based on my experiences only. Perhaps others in the community have found faster, more reliable work arounds.
Posts: 140
Joined: Sun May 31, 2009 2:49 am

Re: Strange characters

Postby jomorlo » Sun Nov 22, 2009 1:00 pm

Hi, after reading your really well explanation:

I tried third option, but I have permission problems. Via FTP I can't change permissions and also to create new folders and paste files....

I created the local file (after changing permissions via FTP on /plugins/generic/customLocale/locale to 777 and I have an es_ES folder with a locale.xml:

Imagen 10.png
Screnshot after create /plugins/generic/customLocale/locale/es_ES/locale.xml
Imagen 10.png (65.68 KiB) Viewed 396 times

Afterthat, I tried to modify string by streng as you said in option 3, but I have permission problems after clicking REVIEW, change the string I want, and trying to save:
Imagen 11.png
Imagen 11.png (117.26 KiB) Viewed 396 times

Thanks in advance for your answer!
Imagen 10.png
Imagen 10.png (65.68 KiB) Viewed 397 times
Posts: 2
Joined: Thu Nov 19, 2009 4:37 pm

Re: Strange characters

Postby jamief » Mon Nov 23, 2009 1:52 am

Those files need write access regardless of the solution you choose, as you have discovered.

If you are using an FTP client like Filezilla, then you should try to go into the web through FTP, RIGHT CLICK the locale folder and use the file permissions option, which allows you to change it from whatever it is to 777 and then apply it to all subdirectories and files under locale.

If that doesn't work, then you should investigate your file permissions at the level of hosting because perhaps you are going to have even bigger problems down the road, for example, the folder that has to hold uploaded files needs read/write permissions as well, or no one will be successfully uploading any documents, and well, of course, you won't be able to perform upgrades on demand.

What you can do to try to see if you have access is to download a copy of the es_ES locale, edit it on your computer. When you are done, DELETE the one on the web and upload the newly edited version. (Always keep a copy of the original on hand.)

The issue of permissions should be looked at regardless. You might be experiencing problems elsewhere because the permissions are not set the way the OCS needs them, and you might find all kinds of files have no read no write, no execution access, rendering a lot of blank page problems for users.
Posts: 140
Joined: Sun May 31, 2009 2:49 am

Return to OCS Technical Support

Who is online

Users browsing this forum: No registered users and 3 guests