Start a new topic

REQ Tolerance for sublanguages in glossary language definition

Would it be possible to let CafeTran be more tolerant for the sublanguage setting in glossaries?


So if I'm working on an nl_BE (target) or en_US (source) project, that I can use my en_EN > nl_NL glossary:


#en_EN TAB #nl_NL.


This constantly having to adapt the languages in the glossary header is quite ...


1 person likes this idea

#en_GB of course


(you see, how ... I am)? ;)

Yes please!

I actually keep all resources (TMX and glossaries) as nl-NL and en-GB only (so no en-US or nl-BE), and only localise the translation at the very end, in MS Word. That way I can maintain only one set of TMXs and glossaries. Sounds pretty crazy, I know, but it works for me.

So every time a client sends me a TMX with either en-US or nl-BE, I manually convert them to en-GB and/or nl-NL (in a text editor) prior to importing them into my CAT tool.

 

Michael: So every time a client sends me a TMX...


TMX files (both for segments and for fragments) don't care about the locale for the SL.


H.

Would it be possible to let CafeTran be more tolerant for the sublanguage setting in glossaries?


TMX memories and Total Recall tables are already tolerant to language variants. Glossaries will be likewise in the next build.


2 people like this

¡Muchas gracias, Señor!


image


IK: Glossaries will be likewise in the next build.


Years ago, you could have changed tab dels into TMX files. That would have saved you a lot of work.


H.

>Years ago, you could have changed tab dels into TMX files. That would have saved you a lot of work.

 

I don't quite understand why you don't let people use the workflow that they prefer? Who are you to tell other people what they should do?


With the utmost respect,


Hans Lenting

Lenting: I don't quite understand why you don't let people use the workflow that they prefer?


Because they DEMAND features that already exist. That's a waste of time, development power, and intelligence. I'm sure you have no idea of the latter.


H.

>Because they DEMAND features that already exist. That's a waste of time, development power, and intelligence. I'm sure you have no idea of the latter.


Not exactly sure what you are referring to with your last remark, but anyway: isn't that entirely up to Igor, which features he likes to develop and add?


After all, it's his software, not yours. (If I'm not mistaken.)

Login to post a comment