The main thing you should be designing for here is the order you want tasks to be processed:
If all tasks should be processed strictly in the order they are queued, you want one queue with all messages on it. The language would then be flagged in the message contents. However, to scale effectively you will still want multiple consumers of this queue, and should set your pre-fetch value low, so that one consumer doesn't reserve messages that another consumer would be ready for.
If the important thing is for each language to be processed as soon as possible, use multiple queues, so that a large number of messages for one language won't delay messages for another language. Having a single consumer for each queue will make these fully independent, and you can use a high pre-fetch value as you discussed. However, this limits your scaling options: if a particular language has a lot of messages, its queue will grow, while other consumers are idle; manually tweaking this, adjusting pre-fetch values and number of processes for each language, is a waste of your time, which is far more expensive than a few CPU cycles.
If you build a pool of consumers, each polling multiple queues with a small pre-fetch value, you will get somewhere between the two: messages will be processed roughly in the order they're generated, but with some messages "jumping the queue" when they are pre-fetched. Note that most RabbitMQ connection libraries will implement the polling part internally, so you don't need to worry about how to build that efficiently; you generally just give the library a callback to run depending on what queue it spotted a message on. If you have one particularly busy queue - or, more importantly, one which takes longer to process - you can set up a separate worker pool for that queue, and leave the others together.