unify translation config

[Waino]

Ding dong, the translation config is dead.

• There is no longer a separate translation config with different structure.
• When translating, a task must be specified. It can either be one of
  the supervised tasks used during training, or a zero-shot task added
  later.
• Translation accepts arbitrary arguments, ignoring invalid arguments
  silently. This allows using the training config, even though many of
  the arguments have no function during translation.
• There is currently no way to automatically generate zero-shot configs.
  Currently it must be done by hand: copypasting and editing a supervised
  task definition.

[TimotheeMickus]

LGTM.

IIUC, we still need to manually provide --src, --tgt, --src_langand --tgt_lang to the translation script?

Ideally I'd want the default translation behavior to be some sort of loop over all tasks in the config. In the long run, we might want to think about supporting a path_test_{src,tgt} so as to allow only a subset of tasks to be tested.

Good enough for now, let's add this multi-test feature for a later rc2.

[TimotheeMickus]

In the long run, it would be good to have some tool for type checking

[TimotheeMickus]

to be discussed. There's a potential risk for confusion by having two very similar types of tasks that need to be configured in slightly different ways.
I think we might want either of the following to:

1. explicitly mark some tasks as test-only (i.e., zeroshot),
2. halt and catch fire in partially / improperly defined tasks (any defined path_src should require device assignment and explode mid-air otherwise).

We might want a big fat DEBUG message about which tasks are defined for which steps (train/val/test), e.g. a tab-spaced table with split as columns and tasks as rows.

[Waino]

Yes, if we generate the zero-shots already in the training config (i.e. before training), then we need to clearly mark the test-only tasks and add validation to prevent accidental mistakes.

However, I see this more as an extra transformation to run on a training config to add the zero-shot tasks, so that you can then easily use it as a translation config. You shouldn't need to decide before training whether you want a particular zero-shot or not.

[Waino]

IIUC, we still need to manually provide --src, --tgt, --src_langand --tgt_lang to the translation script?

The translation script needs:
--config which can be a training config,
--model pointing to the checkpoint to use (same as before: a prefix until the component name starts)
--task_id which must correspond to a task from the config. If using a zero-shot direction, you need to make a copy of the config with the new task added and then reference the name of that task.
--src the test set input
--output the decoded output

You can give --tgt for force decoding / scoring. Although I'm not 100% sure that still works.

Ideally I'd want the default translation behavior to be some sort of loop over all tasks in the config.

Yes, this would be nice. It would require that --src is a path template with variables to fill in (primarily {src_lang}, but could depend on others as well).

Also, there should be a way to list the tasks that you want to include (and/or omit).

In the long run, we might want to think about supporting a path_test_{src,tgt} so as to allow only a subset of tasks to be tested.

I don't really like this approach, as it would mean that you need to specifiy the translation input in the config, and there can be only one.
It kind of works if you only want to evaluate on a single test set, but get's annoying quickly if that is not the case.

Also, it makes it extremely cumbersome to use the model for, you know, actually translating something.

Although for non-batch mode translation (the actual real deal), we would need to repair/reimplement the translation server.