OMP translation with multiple ONIX files

Translations
1

Hi,

I’m trying to sort the delivered files I got from our OMP translators, and the problem is they return me a single ONIX_BookProduct_CodeLists.xsd file, so I have doubts about where it need to be placed.

A $find -name ONIX* returns the following:

1) ./plugins/importexport/native/ONIX_XHTML_Subset.xsd
2) ./plugins/importexport/native/ONIX_BookProduct_CodeLists.xsd
3) ./plugins/importexport/native/ONIX_BookProduct_3.0_reference_notstrict.xsd
4) ./plugins/importexport/onix30/ONIX_XHTML_Subset.xsd
5) ./plugins/importexport/onix30/ONIX_BookProduct_CodeLists.xsd
6) ./plugins/importexport/onix30/ONIX_BookProduct_3.0_reference.xsd
7) ./locale/es_ES/ONIX_BookProduct_CodeLists.xsd

What annoys me is that I diff them and I found some files are exactly the same…

So I got two questions:
a) Why do we have duplicities?
b) What files do I need to overwrite with the new translated ONIX?

My intention (not deep tough) was overwriting 2,5 and 7 and keep the rest untouched.

Thanks in advance,
m.

2

Hi @marc,

Unfortunately the ONIX codelist isn’t maintained by us and as far as I know translation of that file is an unsolved problem. See e.g.:

If you’re willing, I’d suggest contacting somebody here to see if they’ve got a solution yet.
http://www.editeur.org/8/ONIx/

Regards,
Alec Smecher
Public Knowledge Project Team

3

IIRC, the problem is that we are not allowed to ship a translated (as in “inofficial translation”) version of the ONIX codelist. I don’t know if it’s something we should aim for. It’s an/one industry standard, but including it leaves us with a few dependancies (not having translations is one of them).

At the moment I think it’s not a very good idea to have the list sitting in the en_US locale, even with last years patch (*8660* Fall back on English ONIX codelist when localized version isn'… · pkp/omp@ff7069b · GitHub). This lets translators believe they should do something about that file - which I think they probably shouldn’t.

4

That being said… if/when we have translations, we could offer those translations to EDitEUR. They already have a French translation, e.g.

5

Hi all,

I’ll ping my contact at EDItEUR again to see if there’s a preferred way to deal with translations yet. So far we don’t have clear guidance.

Regards,
Alec Smecher
Public Knowledge Project Team

6

I ask again: why do we have duplicities?

Sorry to ask, but… why not? I don’t see any license restrictions.
I mean, if we deliver the official files, why we could not deliver the unofficial ones?

Any way… our stuff did Catalan and Spanish translations.
It file took lot of hours and now work is already done.
Do you want me to commit them to git or should I send it to EDItEUR?

Sorry to anyone, but during the last 8 month our team was working in two OMP translations that only need a final review to be released and they are burning in my hands. :stuck_out_tongue:

Cheers,
m.

7

I missed to ask… should to merge our translations against OMP “master” or “omp-stable-1_1_1”?

I’m asking because “omp-stable-1_1_1” looks too old (before last release) and “master” too new (looks like a dev branch). :frowning:

And what about pkp-lib?

Based on dev and translators documentation, this is my git workflow to sync my old forked repos with “master”:

git clone git@github.com:sdp-uab/omp.git omp-git
cd omp-git
git remote add upstream https://github.com/pkp/omp.git
git fetch upstream
git checkout master
git merge upstream/master
git submodule update --init --recursive

After this, I got OMP in master branch, with “pkp-lib” on “no branch”…

It’s ok if I pull request to this or am I doing something wrong?

Sorry in advance for all this questions if this is documented clearly somewhere.
(A RTFM could be gracefully accepted)

Cheers,
m.

8

Hi @marc,

There are 3 active branches for each of our applications. Taking OMP as an example:

  • omp-stable-1_1_1: This is the branch to use if you want OMP 1.1.1 (the current stable release), plus minor fixes and recommended patches. This is intended for production use. Branches like this are created whenever a release is made. (In git-speak: the branch is created with the release tag as its branch point.)
  • omp-dev-1_1: This is the development branch for the stable line, and will eventually be released as OMP 1.1.2 (if we decide to release a 1.1.2).
  • master: This is the development branch for the next major release, currently planned to be OMP 1.2. This is the least stable branch but includes the most active development work.

If a fix is to be included in omp-stable-1_1_1, then it’ll also need to be cherry-picked forward into the other branches. We can help take care of details like that. For translations of the ONIX files, I’d suggest targeting the omp-dev-1_1 branch.

You’ll get a “no branch” state when you initialize your submodules because git will automatically check out the lib/pkp submodule according to the submodule hash registered in the application repository. You’ll want to check out the same branch in the lib/pkp submodule that you’re using in the application repo.

There’s some more writing on our use of branches on the developer blog.

About translating ONIX codelists, I’ve heard back from my contact there and it sounds like they’re still figuring out how to manage them. He is interested in getting full or partial translations, though, so I’d suggest contacting EDItEUR before beginning a translation – in case they have a partial translation already, which is apparently the case for e.g. Brazilian Portuguese.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like