Label translations: evaluate options for integration with crowdIn

[ahahn-gbif]

use case: use of vocabularies within GRSciColl

Translation of vocabularies does currently not enter the same workflow as other translations, using crowdIn. This makes involvement of our translator community difficult. Internal contacts: KC, @ManonGros

To be confirmed:

• there is no connection between the vocabulary server and crowd-in
• is there a connection with Hosted Portals?

Are there possible solutions to consider, e.g.

• export/import capability
• API level integration with crowdIn
• other?

@MattBlissett , @CecSve could you help evaluate whether this approach (a) makes sense and if so, (b) has a preferred solution?

[CecSve]

For the translator community it would probably be more convenient to work in crowdin.

• there is no connection between the vocabulary server and crowd-in

I do not think so, no. @marcos-lg probably knows better than me though.

• is there a connection with Hosted Portals?

By connection, do you mean if the hosted portals use vocabularies? Then yes, especially GRSciColl related vocabularies are actively being used.

For the solutions I would need @MattBlissett or @marcos-lg input. It would be great if the translated file in crowdin could be used to update language labels in a given vocabulary. This would also alleviate the need for a potential translator scope/role in the registry for the vocabulary server.

[marcos-lg]

I do not think so, no. @marcos-lg probably knows better than me though.
No, there's no connection.

The problem I see is that in the vocabulary API we have some restrictions to avoid having duplicate labels across concepts within the same vocabulary since the labels are used in the pipelines interpretation and to avoid having ambiguities. So it could happen that we can't apply a crowdin translation into a vocabulary update.

For that reason, translators need to be aware that a change in a label can influence the occurrence interpretation and possibly an admin needs to review the changes. One solution could be to have suggestions like we do in GRSciColl.

[ManonGros]

Having an admin approving the final translation would make a lot of sense

[CecSve]

One solution could be to have suggestions like we do in GRSciColl.

Having an admin approving the final translation would make a lot of sense

In that case, if it is actually possible to make the push from crowdin to the vocabulary server, it would make sense to have an admin and manager role eventually, but the language scope for managers should not be implemented since any language suggestions should be handled by the admin who will check potential interpretation issues before including the label. I need to create separate issues for the roles and scopes, but will link to this issue once I have created them, so we can keep track of the discussion.

[CecSve]

I do not think so, no. @marcos-lg probably knows better than me though.

No, there's no connection.

The problem I see is that in the vocabulary API we have some restrictions to avoid having duplicate labels across concepts within the same vocabulary since the labels are used in the pipelines interpretation and to avoid having ambiguities. So it could happen that we can't apply a crowdin translation into a vocabulary update.

For that reason, translators need to be aware that a change in a label can influence the occurrence interpretation and possibly an admin needs to review the changes. One solution could be to have suggestions like we do in GRSciColl.

#143 and #144