PDF Galley Labels (2021-22)


this is a carryover from June 2021, which was closed due to lack of solution. The custom locale plugin only supports en_US, but for bilingual journals featuring Spanish, it should also support en_ES. The plugin has not been updated since February of 2021 (we were at then). Another improvement could be made to the galley labels is to allow generic Español rather than forcing the (España) after it because we all know that more people outside of Spain speak Spanish than in Spain itself. Although I have been able to edit the in the various system files, each time a new upgrade came it reverted those changes. Does offer any solution (there is no upgrade to the plugin I referenced earlier). Thanks!

Arjun Sabharwal (@asabhar)

Hi Arjun,

I hope you receive these comments in a positive way, because I can promise you that they have been written without acrimony, since I am convinced that your intention is to help improve the tool.

But I think it is important that we all learn to work in community and that implies knowing certain unwritten rules such as being very patient and always valuing the work of others.

If I’m being picky, I hope you’ll excuse me.

I will go by parts:

I seem to catch in your mail a certain boredom with the times in which problems are resolved. I know that sometimes it can be frustrating, but in a project of this magnitude there are many factors to take into account and sometimes something can seem slow to us, but it is only because it is complex. This is the inconvenience that derives from projects that have limited resources and are supported by volunteers.

If someone wants to speed up the process and doesn’t have the knowledge to do so, they can always hire a developer and contribute your improvements to the community.

By the way, when you talk about the “carryover from June 2021” do you mean this post? PDF Galley Labels

I don’t remember if this is an explicit rule in the forum, but the good practice is that if a comment is a continuation of a previous thread, a new thread should not be opened, but if you do, leave the reference noted so that when we read it we have context.

In your post I have also seemed to detect a certain complaint about the fact that the dialectal variant is made public.

I must clarify that the es_ES translation is done in Spanish from Spain because that is the dialectal variant of the translation team that maintains it.

I bring it to light because of your “know that more people outside of Spain speak Spanish than in Spain itself” because although OJS and weblate allow you to maintain as many dialect variants as you want, no one, except the es_ES translation team, has dedicated time to that, so to date that is the only complete translation in Spanish.

In any case, your claim seems very legitimate to me and I have to say that I sympathize very much with it.

If someone needs a version in es_MX you are in luck because @dagosalas is (voluntarily) working on it but it will show as “Spanish (Mexico)”.

Having said all this (and I insist that it is not my intention to be picky but I think it is good that from time to time we make the “unwritten rules” explicit) I confirm that the two problems you report prevail in the current versions and that work is being done to correct them.

I add some comments on each one to support your position:

1. custom locales: The customLocales plugin only allows you to modify the English version.

I confirm that also in OJS 3.3.0-10 (with updated plugins) the only language that can be changed is English… according to the translation guide (and common sense), that shouldn’t be the case.

It should be possible to keep custom local translations for all languages ​​and have these customizations persist between upgrades (as long as you don’t change the original English string).

@asmecher, I haven’t been able to find any issue on github talking about it.
Should we open a new one to report it?

2. language label: The language label with the dialect is displayed, even when no dialect variants are active.

Actually in this case it is not an error but this is how OJS works from the beginning.

I share with @asabhar that, when there are no dialect variants, it doesn’t make sense to show the language label with its dialect (ie: “Spanish (Spain)”) and only the language (ie: “Spanish”) should be shown.

This same concern has been taken into account and it has been proposed and accepted to eliminate the dialectal variant in the labels when there are no different dialects.

You can read more about this matter in this thread:

I think we didn’t miss anything.

Thank you Arjun for your feedback and for your patience.

All the best,

1 Like

Hi Marc,

No offense taken–I took your comments positively and thanks for going addressing my concerns in detail. I did not intend to offend anyone either. Yes, that is the post I referred to (I posted it last year), and Roger @rcgillis was the only one to take it up by pointing me to some material in github and to the custom locale plugin, which is strictly for English. Unfortunately, I am not trained in coding, so there is little I want to do to destabilize the platform by making customizations that way. Also, each time OJS gets an upgrade, all previous customizations are wiped out, so yes: I admit frustration over that. I can go into /locales and remove (Espana) from the list…not because I am against the Spanish dialect (Castilian) but because I am trying to support a language (Spanish) professor who would prefer to disambiguate the galley label. English is not followed by a locale either, so it should not take much effort to add just Spanish to the code so that the upgrades include it. At the least PDF should be adequate in place of elongated labels. PDF is PDF everywhere after all. So, I am not asking for dialectical identifiers, just simple labels, like PDF as options across all locales. I did notice that when I switch to Spanish, those labels are only showing PDF but then the English start appearing in the label. So, adding PDF as a generic option should be available and retained after upgrades. Thanks!



Hi @asabhar,

About the custom locale plugin and being able to edit other languages than English – I think you’re encountering Improve ability to edit languages other than the primary locale · Issue #8 · pkp/customLocale · GitHub, which has already been filed and fixed, but a newer copy of the plugin hasn’t been added to the plugin gallery since then. I’ll try to get that done.

(Even once that’s done, the control is a little bit hidden – you have to open up the search filters using the Search button.)

Alec Smecher
Public Knowledge Project Team

Thank you, Alec @asmecher,

That is indeed wonderful to know, and I look forward to the plugin when you release it.

Best regards,
Arjun Sabharwal @asabhar
University of Toledo Libraries

Updates in issue 7352:

Changes will be avaliable in 3.4.

Fantastic, Marc. Thank you! --Arjun

1 Like