Start a new topic

REQ: Ability to change language (or just language variant) after creating project

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?



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.

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.


 

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

 

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

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

 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.

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

Login to post a comment