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.")
Not meaning to add to any polemic, but just in case it's an issue that's being considered now we're further down the line, I'd like to mention that this is still an issue for me, on the practical side.
Obviously I have no idea about the intricacies of the programming side, but if I were allowed to change variant after starting a project that would save a lot of headaches for me.
Yes, it would be ideal if the progress in the glossary/memory were to copy-paste into the new variant (eg, Copy project glossary to new variant? Yes. Overwrite existing entries in new variant? No. // Delete project memory for old variant? Yes / No, copy to new variant. ) but that's not the main thing. I can always go back at a later date and modify the glossary if needed.
It's about continuing in a variant that's not going to keep highlighting correct spelling of the new variant as mistakes because they don't belong to the incorrectly configured variant, and vice versa (not showing mistakes of new variant because it's assuming I want the old variant). That makes QA a pain in the neck, too, and requires a lot of manual checking, which is a bit of a nightmare for larger projects. It also means that although part of the glossary may have been added to the wrong variant, at least it's a partial addition and not 100% of the project.
Unfortunately, although sometimes the change is required due to our own mistake (created the project without checking the variant properly), most of the time it's due to the client changing their minds after we've started. I don't know about other people's clients, but mine do that a lot, at least the direct clients do, even if I've made a point of defining the variant with them before I start (which I usually do).
Again, I understand that the programming side is very different to what we as laypeople may imagine, but because this is a recurring issue and a pain point for several of us (whether or not others have complained), I'd really appreciate it if you could give the idea a rethink in case you come up with a way that would make the change possible in practice, even if imperfectly implemented in terms of glossaries/memories, that would make life easier for those of us that work with variants.