Allow providing glossaries

Thanks for the feedback. I’d have added it already if it could be just a simple text field in the API settings, but every language requires a separate glossary ID.

I could more feasibly (more quickly) implement this as a filter hook that modifies the API parameters. It could work similarly to loco_api_provider_source. What do you think?

That would be great as a first step! At least developers could provide a glossary then.

Are you aware of the following:

Glossaries created via the DeepL API are distinct from glossaries created via the DeepL website and DeepL apps. This means API glossaries cannot be used on the website and vice versa.

https://developers.deepl.com/docs/api-reference/glossaries

Yeah, sure. I created the glossary with Postman

The current dev version has a new filter loco_api_provider_{id} (not yet documented).

This allows you to set limited arbitrary properties on the API configs. It can run at various times, so you’ll have to check the query string to see if it’s being used in a specific language context. I suggest something like this:

add_filter( 'loco_api_provider_deepl', function( array $conf ){
  if( array_key_exists('locale',$_GET) && 'de' === substr($_GET['locale'],0,2) ){
    $conf['glossary_id'] = 'my-glossary-id';
  }
  return $conf;
} );

I’m marking this as resolved as I have no plans to add this into the API settings UI.

Anyone capable of creating glossaries via the API should be equally capable of using this hook, and it provides the flexibility to use specific glossaries for specific PO files.