Hello Hans,
> The primary use of a pick up is perhaps to transport water melons to the market, but if I want to customise my pick up and use it for cruising on the boulevard, what's wrong with that?
Absolutely nothing wrong. And it is also okay to request for a feature that CafeTran might do it for you. However, bear in mind that it is very easy to spoil the finest software design when the program is too much individualized. Imagine tens of users asking for an option or a new button to ignore certain settings. Then the interface would need to satisfy all those users, which is of course infeasible. It is really a question of a balance between the design, usability and practicability. Isn't it one of the main reasons that Mac users love their Macs because the complexity of the interface is either well-hidden or avoided at all cost?
>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.
> zillion tiny time savers
It is not a problem to implement a FEW tiny time-savers. Things get complex and are hard to design/focus/prioritize/manage/maintain/document/promote/etc. if the requests for "zillion tiny time savers" are to be met in ONE product.
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
iCafeTran way/i.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)
The encoding is fine for Ms Office and LibreOffice on Mac.
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):
Igor Kmitowski
CafeTran Espresso 2016 Ichiro - Update 1 is available for download. The users who purchased the program after 22 April 2015, in the new licensing system, do not have to install it anew. They can update it via a simple drag and drop procedure as follows:
1. Run CafeTran.
2. Download 20160205_update.zip file from here (do not unzip or rename the file after downloading) and place it on your desktop.
Note: On Mac OSX, the Safari web browser may unzip the file automatically after downloading. To prevent this, just use the right-click menu and choose the "Download Linked File" command.
3. Drag and drop the downloaded file into the Project Dashboard and restart the program.
4. Drag and drop the downloaded file into the Project Dashboard and restart the program. Second time!
The step 4 above is only for the users who missed the preview (Harbinger) and Ichiro updates with the new icon sets.
The Ichiro update 1 has the following improvements and changes:
- maintaining the applied format during the transfer of the translated text via the system clipboard on Mac OSX.
- showing the information message when the loaded sdlxliff file is not prepared for the translation in CafeTran.
- detection of an error during the new project creation when the user sets the project location folder directly inside the source documents folder, which lead to the creation of multiply-nested folders.
- improvement of the Dashboard appearance (colors and buttons) under Linux GTK look and feel.
- more informative tooltips for the search buttons in the Search bar.
Cheers,
Igor
3 people like this