Bug 3865 - Only default language links are permanently shown in TOC
Only default language links are permanently shown in TOC
Status: REOPENED
Product: OJS
Classification: Unclassified
Component: User Interface
2.4.x
PC Linux
: P2 enhancement
Assigned To: Alec Smecher
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-13 04:13 PST by Marc Bria Ramirez
Modified: 2014-10-20 04:09 PDT (History)
6 users (show)

See Also:
Version Reported In:
Also Affects:


Attachments
Patch against PKP pre-release (536 bytes, patch)
2009-07-02 16:51 PDT, Alec Smecher
Details | Diff
Patch against OJS pre-2.3 CVS (9.94 KB, patch)
2009-07-02 16:51 PDT, Alec Smecher
Details | Diff
Patch against OMP pre-release (10.32 KB, patch)
2009-07-02 17:09 PDT, Alec Smecher
Details | Diff
Patch against OCS pre-2.3 CVS (9.59 KB, patch)
2009-07-03 09:04 PDT, Alec Smecher
Details | Diff
Display language configuration (76.22 KB, image/png)
2014-09-22 04:59 PDT, Marc Bria
Details
TOC show title and galleys as configured (91.34 KB, image/png)
2014-10-20 04:08 PDT, Marc Bria
Details
"Primary language" need to be reachable for Editors (added dropdown in metadata) (114.05 KB, image/png)
2014-10-20 04:09 PDT, Marc Bria
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Bria Ramirez 2008-11-13 04:13:39 PST
Scenario:
OJS 2.2.2.0 (patched from OJS 2.1.1.0)
with 3200 patch applied: http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=3200

Problem:
Articles that are localized with a language different than the active one, are not included in magazine's table of content.
Only default language links are permanently shown (independently from visitor's lang).

Example:
On a magazine with Spanish as default lang, if an article only includes a PDF in French, it's link is only shown when visitor selects french language.

Expected result:
Interface language is up to user's preferences but content must be shown for every language.
At the maganize's TOC, a link to every localized PDF (showing it's language) would be appreciated for our readers.

Comments:
Probably this is more a OJS feature than a bug. I mean, I can imagine other contexts (where every article is always translated to every magazine's lang) where could be useful the way OJS is working now, with no separation between user's interface and content's language... but for smaller magazines, it's certainly an issue.
Comment 1 Juan Pablo Alperin 2008-11-13 04:41:03 PST
On first thought, this seems like a good idea.  

I am thinking that, in the table of contents, there could be a link saying "Other Languages" and in the "abstract view" (where there is much more room) we can have links to all the available languages.
Comment 2 Marc Bria Ramirez 2008-11-13 07:49:24 PST
Thanks Juan.

I personally like the way Drupal deals with this.

i18n module let Admin select how content will be shown between:

[] Only current language and no language
[] Only current and default languages and no language
[] Only default language and no language
[] Only current language
[] All content. No language conditions apply

In big magazines (I mean, with big resources), first to forth choices will be popular... wile in small-middle ones, the last choice will be the best.

Furthermore, to avoid repetitive info in TOC, I suggest keep links as now, not indicating the active visitors language if fits with user's preferences.

I mean, if a visitor selects English as his/her interface language, PDF link will be "PDF" instead of the long "PDF (ENGLISH)" that will be shown when interface is changed to Spanish (or whatever).

I'm quite sure implementing this suggestion means a huge work in development terms... so I suggest a SJF (Shortest Job First) approach: A simple patch, then include 2 choices in admin settings, finally 

Let me know if you think external help could be useful: I feel quite confident in developing a "dirty hack" to patch if this issue is not in OJS priorities, although I'm full incompetent to deal with the full suggestion.

Thanks you all for the great development,

m.
Comment 3 Marc Bria Ramirez 2008-11-13 07:57:47 PST
I missed to say that Drupal's i18n module options traduced to OJS could be something like:

[] Show only "current language" articles.
[] Show "current" and "default" languages.
[] All content: No language conditions apply.

Hope this make sense. :-)

Note: This is not a "Bug" instead of a "Feature Request"... that I was warned in OJS forums to publish at your bugzilla. Am I following the right netiquette?
Comment 4 James MacGregor 2008-11-13 09:59:09 PST
Thanks Marc, this looks great. I've changed the severity from 'normal' to 'enhancement' so that it shows up as a feature request; but this is not a huge deal. 
Comment 5 Alec Smecher 2009-02-16 18:25:30 PST
The new setup options proposed here look great, but are beyond the scope of a point release and will be deferred to v2.3. In the meantime, if you'd like all languages to be listed, I would suggest a work-around: designate all galleys as the journal's primary locale, and name them after the language they provide. The current structure accommodates large journals (i.e. those that have full multilingual content and don't want entries listed beyond the current language), and the work-around better accommodates journals that don't have content fully translated.
Comment 6 Alec Smecher 2009-02-16 18:26:03 PST
...and I'm entirely open to suggestions and discussion on this.
Comment 7 Marc Bria Ramirez 2009-02-17 02:19:16 PST
Thanks Alec for the feedback.

The solution you suggested is the same that we finally adopt in our brand new 2.2 installation.

If it's too late for 2.3, do you think it could be improved in 2.4?

I suppose 2.4 means at least a year an half from now, so meanwhile (if I get time for this) I will try to develop a dirty patch for "All content: No language conditions apply."

Any clue about where to start looking?
Comment 8 Alec Smecher 2009-02-17 07:41:22 PST
Marc, you should be able to do this by simply changing the getLocalizedGalleys function in classes/article/PublishedArticle.inc.php to:

function &getLocalizedGalleys() {
        $allGalleys =& $this->getData('galleys');
        return $allGalleys;
}

...I haven't tested this, but it should work.
Comment 9 Marc Bria Ramirez 2009-02-20 08:49:16 PST
Wonderful Alec !! Just what we wanted. :-)

Here the results of alec's patch (and a little tunning on templates):
http://psicologiasocial.uab.es/athenea/index.php/atheneaDigital

BTW, I changed the templates because at the presentation layer the lang name of each pdf (for instance "PDF (Español (España))") was too long and were not translatable as far it string is taken from xml's lang headers instead of a "message" tag.

Make sense to open a new feature-request to make lang names able to be translated or do you think this is too peculiar?

Thanks a lot for the solution,

m.

PD: I change this issue to RESOLVED but with REMIND tag, to keep in mind defining OJS 2.4 new features. ;-)
Comment 10 Alec Smecher 2009-02-23 18:00:43 PST
Marc, you should be able to fine-tune the language names in registry/locales.xml. We'll probably keep shipping them as they are -- someone may want to use two kinds of Spanish, for example, and they'll need to be able to differentiate -- but it's easy enough to change in the XML file.
Comment 11 Marc Bria Ramirez 2009-02-24 01:58:33 PST
I wanted to keep consistency with your lang name descriptions and just change the way those names were shown, but if you say there are no collateral effects (for instance, when harvesting...), I will roll back those changes to the simplest solution.

Any case, a "showLanguageName" message will be more flexible, don't you think?

Thanks Alec,

m.
Comment 12 Alec Smecher 2009-02-24 08:23:41 PST
Marc, no, there would be no collateral effects; the locale names are free to change as you like. The names in registry/locales.xml are simply for information purposes, so adding another locale key would duplicate that info unnecessarily in my opinion (there's no real difference between editing a locale file and editing the locales.xml file).
Comment 13 Alec Smecher 2009-04-21 18:13:51 PDT
Re-opening so we don't forget.
Comment 14 Alec Smecher 2009-07-02 16:51:19 PDT
Created attachment 2078 [details]
Patch against PKP pre-release
Comment 15 Alec Smecher 2009-07-02 16:51:47 PDT
Created attachment 2079 [details]
Patch against OJS pre-2.3 CVS
Comment 16 Alec Smecher 2009-07-02 17:09:48 PDT
Created attachment 2080 [details]
Patch against OMP pre-release
Comment 17 Alec Smecher 2009-07-03 09:04:35 PDT
Created attachment 2082 [details]
Patch against OCS pre-2.3 CVS
Comment 18 Alec Smecher 2009-08-25 17:01:38 PDT
Form language pull-down list separated from UI language pull-down list; deferring the rest until later.
Comment 19 bdgregg 2011-01-04 12:50:28 PST
Alec,

We are running into the same scenario as Marc was.  I see the patches above and that they are included in the 2.3.3.1 version we're running on.  I also see the suggested work around of changing the following function (although not tested here yet):

function &getLocalizedGalleys() {
        $allGalleys =& $this->getData('galleys');
        return $allGalleys;
}

Could I suggest making the above change an option in the Journal Managers Language settings?  

In other words a check box or such to switch between the A.) display all of the language galleys submitted in the TOC, B.) only show the currently selected language galleys in the TOC.

This would help us not editing the core software and stop confusion when some galleys are only showing up under one language ;-)

Thanks in advance,
Brian Gregg.
University of Pittsburgh.
Comment 20 Alec Smecher 2011-01-07 09:30:38 PST
Scheduling for attention in the next release.
Comment 21 Alec Smecher 2012-03-12 10:01:37 PDT
I think the best solution would be to make this an option as Brian suggests. That means it'll require a couple of new locale keys, which means it'll need to wait until 2.4.
Comment 22 Alec Smecher 2012-03-12 12:03:52 PDT
On second thought -- this has already been solved as part of bug #3865 (to be released in 2.3.7).

*** This bug has been marked as a duplicate of bug 6762 ***
Comment 23 Marc Bria 2012-03-13 02:21:14 PDT
Although in this thread we all have quite the same needs I know magazines interested in a third case: "Show current language + default".

So, instead of a checkbox I would suggest a few radio buttons with Brian's options and the third case as follows:

( ) All content: Display all of the language galleys submitted in the TOC, 
( ) Current and default: Show currenty selected and default language galleys in TOC. 
(*) Current: Only show the currently selected language galleys in the TOC.

Please notice, that the writing (at least my adding) need to be reviewed by a native English speaker.

To keep backward-compatibility, last choice is the one that need to be marked by default.

> Could I suggest making the above change an option in the Journal Managers
Language settings?

I also believe it's is natural place. :-)

Thanks for the great work.
Comment 24 Alec Smecher 2012-03-13 15:43:25 PDT
OK, marking for further work in 2.4.
Comment 25 Marc Bria 2014-09-22 04:59:22 PDT
Created attachment 4054 [details]
Display language configuration

A proposal to add a new section to the language configuration.
Comment 26 Marc Bria 2014-09-22 05:13:58 PDT
We arrived to the conclusion that we need to rethink it a little so we are proposing to add two new questions in the config/lang page to let the admin decide about:

a) How title is shown when different metadata.
b) How lang is shown in galleys.

This screenshoot shows it better:
http://pkp.sfu.ca/bugzilla/attachment.cgi?id=4054

Does it make sense to you?

I nearly finish with the coding (although I don't mind to reformulate it all if you have a better suggestion) but the point is that I'm unsure about how to deal with the "original language" of the article. 

I mean, OJS asks about the "primary language" of your submission. Could be this considered the "original" lang, isn't it? 

I assume yes, but how could it be reached? Looks like "getLanguage" returns the metadata language for "indexation" that BTW is in a different iso format ("en" instead of "en_US").

As I said, I really don't mind to redo it all but I like to contrib something to avoid multilang journals patching OJS on every new release.

Take care,
m.
Comment 27 Marc Bria 2014-10-09 03:56:49 PDT
> I mean, OJS asks about the "primary language" of your submission. 
> Could be this considered the "original" lang, isn't it? 

I assume yes to this, but we noticed that "original language" (better "original" than "primary") it's only asked during the submission and not shown/modified anywhere.

Seams logical to us to modify article's metadata form to let editors see and modify this metadata, don't you think?

I'm working on this right now.

I hope I will be able to submit patches against 2.4.5 in a week or so.

Hopefully you will find them useful to be taken in consideration for the next official release.
Comment 28 Marc Bria 2014-10-20 04:07:27 PDT
A few more screens added and opening the discussion to forum to get more feedback.
http://pkp.sfu.ca/support/forum/viewtopic.php?f=9&t=13021
Comment 29 Marc Bria 2014-10-20 04:08:53 PDT
Created attachment 4058 [details]
TOC show title and galleys as configured
Comment 30 Marc Bria 2014-10-20 04:09:43 PDT
Created attachment 4059 [details]
"Primary language" need to be reachable for Editors (added dropdown in metadata)