Self-explanatory really. Because CT retains language settings from the last project, I often find myself some way through a project before realising that the project setting is en-US, instead of en-GB (which means lots of spurious red underlinings).
I can't see any obvious reason why this shouldn't be trivial to do. (Obviously I wouldn't expect any resegmentation or anything crazy like that). OK, you might have to reload Hunspell (but I don't mind closing the project, making this change and reloading).
It is not possible because it would involve changing languages for other resources too (e.g. TMs, glossaries, Total Recall, spellchecker). And this, in turn, would require unloading and loading them all again. The whole chain of events is language-specific. Even segmentation and parsing of the segments may depend on which source language is set. You can use Project Templates to switch the language pair quickly before creating a new projects.
Apart from the above, it would break the uniform structure of your current TM and glossary language settings in segments/terms. Imagine half of the source segments in one language variant and the other half in another. It would create a lot of mess hard to repair. Project segments, ProjectTM segments and Project terms should be uniform and in agreement. Once you start your project with one settings, you can't really change them half-way.
> Sorry Igor, but I just can't see the problem.
If the language variant problem looks trivial to you, why don't you simply keep on translating in another variant set in your Project after realizing your mistake?
> I said I thought that allowing it to be changed should be trivial.
No, it is not. It would require a lot of structural of changes to the program. By the way, you can easily change the language of the spell checker on the current project in the Edit > Spell checker menu, which I guess is the core issue in your request.
> By the way, you can easily change the language of the
spell checker on the current project in the Edit > Spell checker
menu, which I guess is the core issue in your request.
That's what I needed. Thanks!!
OK, I concede, that's easier than coding the change. (But isn't it as simple as changing en-US to en-GB in the xlf file?)
> But isn't it as simple as changing en-US to en-GB in the xlf file?
Besides the spell checker's language, the source language of the project determines the header in the glossaries, the language name is TM translations units, column names in Total Recall tables. They all would need to be closed and opened again to reset the language.
I can see that some users might be caught out by just assuming that a change of language will magically change all of these things, but that can be solved with a simple pop-up message (along the lines of ("Please note that changing the language will not change the language for previously saved translation units or project glossaries.")