CafeTran

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).

Igor?

Two things:
1. None of those arguments apply when changing language variant. That's actually my use case, but I left the original question general, becaue I could see that others might want to change the main language.
2. Even given that above, why not let users change this, then close and restart the project with the new settings?
Clearly you don't want to redo the segmentation (that would be a real hornet's next), but that's not an issue for my first case and not much of an issue even for the second.

At least for the first case (language variant) this should be trivial to do and would help me enormously.

 

Sorry Igor, but I just can't see the problem.
Having a TM with both en-GB and en-US segments is just not in a million years a problem.

And what does "half of the source segments in one language variant and the other half in another" even mean???? The source segments are in whatever form the customer supplied them. What does it matter to the customer (or translator) what some label in some xml file they'll never see says?

And again: "Project segments, ProjectTM segments and Project terms should be uniform and in agreement." what does that even mean? Except in very rare cases, I don't believe that anyone has language variant-specific glossaries and TMs. The variant is simply irrelevant in these cases, doubly so for glossaries.

 

"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?"

You're misinterpreting my comments, I didn't say or imply that the "language variants problem" (by which I take it you mean the problem caused by having the incorrect language variant set) was trivial (though it's clearly not life-threatening, either). I said I thought that allowing it to be changed should be trivial.
I think it would be helpful if you would engage seriously with the points raised on this forum.

 > 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?)

> 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 the language.

So I can see all those things, it's just that they seem insignificant to me.
Point by point:

The spell-checking language: this needs changing anyway, whether or not you allow the user to 'officially' change the language in the project settings. Given how easy it to change manually, as you point out above, it should be pretty simple to change it automatically, no?

The header in the glossary: This has already been set, doesn't need changing and wouldn't require the glossary to be reloaded.

The language name in the TM and/or in Total Recall: I'm not suggesting foo a moment that existing TUs should be changed, However, it is surely better to get it right from now on, than to continue to get it wrong for the sake of consistency. (I can't imagine any circumstance in which that consistency would matter.)
And again, you would not need to reload the TM, just use the new language when saving future new TUs to the TM/Total Recall database.
Having a mix of varients in a TM is certianly not a problem in principle. I just had a look at one of my large general TMs, and it has TUs which are en-GB, EN-GB, en-US and EN-US. It's never been a problem.

Now if you tell me this is too complicated, fair enough, you're the one who has to code it, but I can't see why this should be.

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.

Thanks!