Bug 3865

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.

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.

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?

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. 

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.

...and I'm entirely open to suggestions and discussion on this.

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?

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.

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. ;-)

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.

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.

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).

Re-opening so we don't forget.

Created attachment 2078 [details]
Patch against PKP pre-release

Created attachment 2079 [details]
Patch against OJS pre-2.3 CVS

Created attachment 2080 [details]
Patch against OMP pre-release

Created attachment 2082 [details]
Patch against OCS pre-2.3 CVS

Form language pull-down list separated from UI language pull-down list; deferring the rest until later.

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.

Scheduling for attention in the next release.

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.

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 ***

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.

OK, marking for further work in 2.4.