CafeTran

• Mine, of course

• Mine
  

• Whatever you want it to use for
  
• Whatever you want it to use for
  

>don't demand or require other people to do it for you

as far as I know, I didn't ask for nada in this regard, but even if I did (very well possiblo, gringo) than I'd say that that's perfectly legit

as long as I avoid the word 'should' that triggers a certain developer's sensitivity

he's an autonomous person too

if he'd like to hear what he 'should' do, he'd be working for a boss by now

>However, bear in mind that it is very easy to spoil the finest software design when the program is too much individualised.

Yep. I understand. And it's indeed a danger for CafeTran, currently such a great and fine tool.

Did I already say that I just love this automated handling of spaces while dragging text around? It completely reactivated my eagerness to polish my target sentences. A little tweaking here, a little optimising there.

"Small feature" (in fact it's a great one) with big impact (on my every-day work).

Yesterday I had to do a review in Studio and had to play around with it's Find dialogue box to find all instances of an incorrect term. Oh man, the difference between this tiny dialogue box with all it's counter-intuitive and extremely unproductive behaviour and CafeTran's F/R dialogue box cannot be described.

And that's just one feature (though a very important one). In most other aspects CafeTran also scores better.

Yes, all this could be spoiled. However, personally, I think that the risk of spoiling's rather present at the level of TM matching and the like, and not so much in the addition of an extra facilitator: a 'tiny' new keyboard shortcut that will save you a lot of clicks (like: Navigate to the first bookmark found).

Isn't this just beautiful? I really enjoy looking at images like these:

So, what I'm basically saying here, is that in my understanding there are two categories of modifications: the dangerous ones and the not so dangerous ones. With this restriction, that even the not so dangerous ones can f**k up a very fine software tool.

And to elaborate just a little further on this: I think that it's your careful listening to many small requests (of the not so dangerous category) of your users (and evaluating and weighing) that has brought CafeTran this far: by far the nicest tool in Mexico!

I never understood why those other programmers are so afraid to add a tiny time saver (with big effect on productivity), of the category 'Add the current selection of the text to the Find field' (yep, some mothers do 'ave 'em).

I can only speculate about the reason. Is it because they're lazy (very unlikely), because they are only allowed to touch one tiny component of the software (quite likely), because they aren't really enjoying to code (perhaps), because they aren't 'free minds' (god may know ...)?

The communication of all these zillion tiny time savers, in comparison with other tools, would be a nice marketing challenge.

I noticed that the Copy Markdown to RTF service uses **strong** instead of *bold*. I didn't like that so I modified the .pl inside the service. Then I noticed something else: the Markdown has to be applied neatly: *bold* and not *bold *. The latter form is created when people apply bold etc. in Word: nobody selects the word bold only, instead the trailing space is most of the times included. Okay, I thought that I'd just mention this here.

In the source the 'wrong' formatting, in the target the required one. And then we of course also have the 

I've now updated and am using the latest build on Mac. There seems to be an issue with the encoding:

I've activated Copy target to clipboard and when I switch to TextEdit and paste, I get:

(same issue as with the original service, before I modified it -- this, however, is native CafeTran stuff)

IK: The encoding is fine for Ms Office and LibreOffice on Mac.

I think the screenshot above shows *.rtf in TextEdit. Which is why the formatting in the clipboard workflow should be applied after translating. In other words, the way the workflow was set up.

H.

cafetran.training: I modified the .pl inside the service. 

There's nothing in the plist that points to "bold" versus "strong," and since the nature of plists, that's a good thing. There's probably something on "bold" in the Perl script, but I don't understand Perl, and I wouldn't dream of changing things in it.

H.

>The encoding is fine for Ms Office and LibreOffice on Mac.

Okay then, that should be enough. I was testing with TextEdit (OS X's default editor).

I confirm that the addition of formatting via the context menu in the Target segment pane is possible when MS Word is used as an editor (word processor):