Author names in English and Farsi (Arabic etc)

[msaghaei]

As a transient remedy until functional support by PKP team, following trick may be used to enter author names in up to two locales: An ASCII encoding locale such as english and a multibyte locale such as Farsi or Arabic
1. In the articale metadata enter author names in both locales. Of course this doubles the number of authors, but by applying the following modification in template files you can show only one set of author names at a time. It does not matter how to intermix the order of two locale names but you must keep the order of authors for each locale independently. An easy to remember method is to enter all author names for the first locale and then repeat it for the next local.
2. in the file templates/issue/issue.tpl use mb_detect_encoding function to pick only those names which is relevant to the current page locale. A possible way of doing this is to insert following code

Code: Select all

         {if $currentLocale eq "en_US"}
            {if mb_detect_encoding($author->getFullName(), "ASCII, UTF-8") eq "ASCII"}
               {$author->getFullName()|escape}{if !$smarty.foreach.authorList.last},{/if}
            {/if}
         {else}
            {if mb_detect_encoding($author->getFullName(), "ASCII, UTF-8") eq "UTF-8"}
               {$author->getFullName()|escape}{if !$smarty.foreach.authorList.last},{/if}
            {/if}
         {/if}


after

Code: Select all

   <td style="padding-left: 30px;font-style: italic;">
      {foreach from=$article->getAuthors() item=author name=authorList}


Similar modification may be applied to the templates/article/article.tpl to view the author names in the abstract (or html full text) view, only in the selected page locale.

To append the name of the first author at the end of the breadcrumb path in the abstarct view, following code may be inserted

Code: Select all

      {foreach from=$article->getAuthors() item=author name=authorList}
         {if !$firstAutor}
         {if $currentLocale eq "en_US"}
            {if mb_detect_encoding($author->getFullName(), "ASCII, UTF-8") eq "ASCII"}
               {assign var="firstAutor" value="1"}
               {$author->getFullName()|escape}
            {/if}
         {else}
            {if mb_detect_encoding($author->getFullName(), "ASCII, UTF-8") eq "UTF-8"}
               {assign var="firstAutor" value="1"}
               {$author->getFullName()|escape}
            {/if}
         {/if}
         {/if}
      {/foreach}


after

Code: Select all

   <a href="{url page="article" op="view" path=$articleId|to_array:$galleyId}" class="current" target="_parent">


Use "en_US" if your ASCII encoding locale is English otherwise replace it accordingly.

Other places containing name of authors may also need similar modification (e.g. search and brwose pages)

An example site is the current issue of Journal of Isfahan Medical School at http://journals.mui.ac.ir/jims

A possible benefit of this method is that you can search the auhtor names in both languages.
Mahmoud

[mj]

Hi Mahmoud,

Thanks for the detailed technical explanation! I'd like to ask a few questions of clarification, if I may:

1) You mention this as "a transient remedy until functional support by PKP team"; I'm not sure I understand what the exact deficiency is that needs to be corrected. Could you please provide some more detail for us to work with?

2) Strictly speaking, if your journal is using UTF-8 to encode metadata such as author names, there should be no need to switch between encodings; UTF-8 is a superset of most other encodings, including US-ASCII and Latin-1 (aka ISO-8859-1). The recent OJS 2.2 release allows multi-locale metadata, so there should be no need to modify the templates or use the PHP mb_ extension functions (which may not exist on every platform OJS is installed on) if UTF-8 is supported. Your approach is interesting -- I would be interested to hear more about your rationale.

I'd also like to add that you've done a fantastic job with your journal site, specifically handling LTR and RTL style and layout when switching between English and Farsi. Very nicely done! A quick check of the current Farsi translation status (http://pkp.sfu.ca/ojs-languages/farsi) shows that it's currently incomplete; we'd be most grateful for any contributions you'd be willing to make for a complete Farsi translation of OJS 2.2.

Finally, for interest sake, I would recommend that anyone exploring character encoding issue stay away from US-ASCII if possible; it is the smallest character set (255 characters in total), and cannot represent even basic accents, mathematical symbols, etc. Most PHP, MySQL, etc. installations are set to Latin-1 by default, which although not as flexible as UTF-8, will avoid many more encoding problems than US-ASCII.

Best regards,

[msaghaei]

Hi MJ

Thanks for reading and commenting the post. First of all I should say that I had used the term 'locale' in place of language, and strictly speaking my intention was the problem with journals with more than one supported language. The problem is described below.

1) Regarding the "a transient remedy". I tested the latest version of ojs (ie 2.2), although for many fields it supports separate data entry for each supported locale, but unfortunately it does not allow to enter the names (first, middle, last) in more than one locale. For example in some journals in our installation there are two suppoted languages, ussually English and Farsi. In such installation users are able to enter article title and abstract in each language separately, but regarding the names you may choose only one language. It is not possible to enter names in both. suppose that the user choose to enter the names in English, the drawback is that when the visitors see the TOC of an issue, and change the page language to Farsi, in TOC the article titles are seen in Farsi, but the author names in English. The reverse will be seen when the user enter names in Farsi, with the aditional disadvantage that the names are not seen correctly if the required Farsi font is not available on the client machine. Some of the journals in our installation changed to mono-locale to avoid this discrepancy, and some of them stoped to use OJS, just because of this problem. I am sure this is also a serious problem for other language Like Arabic, Chinese, Japanese, etc. Before releasing 2.2 version we had a great hop that this shortcoming be addressed. When I assured that this problem is still exists we sought overcoming this problem by modifying the templates, and I think the suggested method is relatively easy and do not require to change the code in php files or working with the database. Perhaps to address this issue in a more logical and structural way, it needs extensive surgery into the ojs code and database.

2) switching between encodings: As I said my intention was switching between page languages by choosing the language from the drop down menu (Language Toggle Block). So the user do not select any special encoding. He/She simply enters the data in certain language. When entering data in English, the resultant encoding automatically tends to by US-ASCII and when entering Farsi data it will be UTF-8. Regarding multi-locale metadata compatiblity of OJS 2.2, as i tested it, names are supported in only one language. May be this is natural coding, and names like emails, web addresses, etc, must be entered in latin alphabet

3) We are translating version 2.2 and it will be ready in about one month. At that time certainly we will contribute.

Best regards,

Mahmoud

[mj]

Hi Mahmoud,

Thanks for your detailed response. Here are my thoughts on your comments.

1) My apologies, I had misunderstood what you had meant by metadata. Although we don't currently support author names in multiple languages, if you're seeing this as a common case where yours and other multilingual journals find this limiting, we'd be happy to consider it for inclusion on the list of improvements for the next OJS release. To the best of my knowledge, it shouldn't require "extensive surgery" to add this into the OJS codebase, but I don't believe it's completely trivial, either. Your approach for modifying the templates is a very creative interim solution, however.

2) If your journal is configured to use UTF-8 as the encoding throughout, all of your users should be able to enter data in both English and Farsi (and most other global languages), and switch between languages without ever having to change or otherwise deal with character encodings. When entering data in English or, as you say, emails or other Latin-style characters, they are all fully supported within UTF-8; the encoding should not "automatically" change to US-ASCII. This is the purpose of UTF-8: to enter characters in any language: Farsi, English, Arabic, Chinese, etc, -- or even a mix within the same string -- and never have to change encoding.

3) This is absolutely wonderful news! We are looking forward to having a complete Farsi translation, and are most appreciative of your generous contribution to OJS.

Best regards,

[msaghaei]

Hi MJ

Thank you for good news regarding possibility of improvement in the next OJS release. Should we wait for the next major release (e.g. 2.3) or it may be implemented as a minor one (2.2.1 for example). In either case I think following fields should be considered as multi-lingual so that users can enter data in more than one language simultaneously. May be these fields should be removed from the users and article_authors tables and inserted as records into the user_settings and article_author_settings tables respectively.:
salutation, first_name, middle_name, last_name, gender, discipline, initials, affiliation, mailing_address, country

In my guess in addition to database modifications, many files in the OJS codebase may need revisions. I hope the list of modifications is not much high as to prevent for implementing them as the release 2.2.1
If you think these modifications are not very difficult to implement, I would appreciate if you provide some hints on how to do this. If we wait until the next major release, at that time we should revert the modifications which I has already mentioned (ie deleting extra author names in the database and entering the names for each language separately). Whether this is a difficult and time consuming task depends on when the next release will be ready.

Best Regards,

Mahmoud

[mj]

Hi Mahmoud,

Apologies for the delay -- off the top of my head, I would say that your current workaround is probably a better way to go than modifying the OJS codebase and database tables for now. I'm not as familiar with the locale handling as Alec is, but again, my best suspicion is that if you can wait for the next OJS release, that would likely be the wisest route.

To my knowledge, we don't have a specific schedule for the next release of OJS, although we will be discussing this in the near future. We generally include new functionality based on what will be most useful to the largest number of people, not necessarily technical complexity, so if this is such a feature, then it would likely be a prime candidate for inclusion in whatever major or minor release is next. I'll be sure to bring it up at our next team meeting.

Best,