Studio 2014 keeps complaining about dates Thread poster: Piotr Bienkowski
|
|---|
I am making more and more use of the QA feature. But Studio keeps complaining about dates not being properly localized, while they are!
For example 5 stycznia 2005 r. is a proper localization of 5 January 2005. I get the same when I translate into US English, and use the proper Month Day, Year format. Any idea why? It is so annoying!
Thanks,
Piotr
| | | |
Shai Navé 
Israel
Local time: 19:18
English to Hebrew
+ ...
| Check the settings | Nov 21, 2013 |
File > Option > [Relevant Language Pair] > Translation Memory and Automated Translation > Auto-Substitution > Dates and Times
And make sure the date and time formats match what is appropriate for the specific language at hand.
| | | |
Ines Burrell
United Kingdom
Local time: 17:18
Member (2004)
English to Latvian
+ ...
| Studio localises dates incorrectly | Nov 21, 2013 |
This is a known problem with Studio. I have no idea where they have got their data from, but it is wrong in several languages and definitely wrong when it comes to Latvian so you might be in the same boat. I contacted SDL asking how to change the format and they said that as far they are concerned the dates are correct and if I believe otherwise, I should submit a suggestion about improvements (like that is going to change anything!). As it is, the auto-substitution of dates in all the Studio ve... See more This is a known problem with Studio. I have no idea where they have got their data from, but it is wrong in several languages and definitely wrong when it comes to Latvian so you might be in the same boat. I contacted SDL asking how to change the format and they said that as far they are concerned the dates are correct and if I believe otherwise, I should submit a suggestion about improvements (like that is going to change anything!). As it is, the auto-substitution of dates in all the Studio versions is redundant for many languages. Having read discussions on the subject I can only conclude that SDL could not care less. ▲ Collapse
| | | |
| So it appears that in order not to get annoyed... | Nov 21, 2013 |
Burrell wrote:
This is a known problem with Studio. ...
... is to disable date checking in Studio.
@Shai Nave - been there, nothing seems wrong there, but will check again.
Piotr
| | |
|
|
|
| Need more info... | Nov 21, 2013 |
Hi Piotr et al.,
Studio takes it's dates from your operating system. So whatever Microsoft thinks the dates should be, Studio thinks the same. If you look here you'll get the idea: http://goo.gl/p8ufKj
I tried to test your date... en - pl but had to change the format of the date in en(US) because there was a comma missing (for this flavour of en according to said rules) and then I see thi... See more Hi Piotr et al.,
Studio takes it's dates from your operating system. So whatever Microsoft thinks the dates should be, Studio thinks the same. If you look here you'll get the idea: http://goo.gl/p8ufKj
I tried to test your date... en - pl but had to change the format of the date in en(US) because there was a comma missing (for this flavour of en according to said rules) and then I see this:
No errors and the dates are recognised. You need to be specific with the language flavours and what you are using in order for us to comment on it.
Regards
Paul ▲ Collapse
| | | |
| So, in other words.... | Nov 21, 2013 |
SDL Support wrote: Hi Piotr et al., Studio takes it's dates from your operating system. So whatever Microsoft thinks the dates should be, Studio thinks the same. If you look here you'll get the idea: http://goo.gl/p8ufKj I tried to test your date... en - pl but had to change the format of the date in en(US) because there was a comma missing (for this flavour of en according to said rules) and then I see this: No errors and the dates are recognised. You need to be specific with the language flavours and what you are using in order for us to comment on it. Regards Paul
I need to fix the source not to get errors?
What about the other case I mentioned in a private e-mail message, when the error was raised while translating into EN-US?
Piotr
| | | |
| email message | Nov 21, 2013 |
Piotr Bienkowski wrote:
I need to fix the source not to get errors?
What about the other case I mentioned in a private e-mail message, when the error was raised while translating into EN-US?
Hello Piotr,
I just looked at this and I can't repro the error you show reported. Can you send me the Project?
On fixing the source... I have no idea. I don't know what the source language/flavour was in your previous example. It looks as though it should be en(US) so I used that... and when I do then yes, correcting the source is the way to go.
You could use the SDLXLIFF Toolkit to correct all dates in the source in one go easily enough.
Perhaps use something like this.
Search source for:
(\d{1,2} \w+) (\d{4})
Replace with:
$1, $2
Regards
Paul
| | | |
Erik Freitag
Germany
Local time: 18:18
Member (2006)
Dutch to German
+ ...
| Shouldn't SDL do better than that? | Nov 22, 2013 |
I understand that using information from Microsoft looks like a good idea at first glance, but I think SDL should do better than that.
I can see a pattern here:
- You don't need to merge segments across paragraph marks, they shouldn't be in those places to begin with! -> SDL blames the author of the source text.
- People are constantly having problems with MultiTerm. -> That's a JAVA probl
... See more I understand that using information from Microsoft looks like a good idea at first glance, but I think SDL should do better than that.
I can see a pattern here:
- You don't need to merge segments across paragraph marks, they shouldn't be in those places to begin with! -> SDL blames the author of the source text.
- People are constantly having problems with MultiTerm. -> That's a JAVA problem, SDL can't do anything about it.
- I have to manually edit every single date in my target text, as the format in German isn't correct -> That's Microsoft's fault!
▲ Collapse
| | |
|
|
|
George Cook
United Kingdom
Local time: 17:18
French to English
+ ...
| Six of one... | Nov 22, 2013 |
It seems to me that a lot of the SDL-bashing on here is only one side of a reasoned argument, so for what it's worth, here's the other side...
You don't need to merge segments across paragraph marks, they shouldn't be in those places to begin with! -> SDL blames the author of the source text.
As I understand it, it's more that it's extremely problematic to reliably implement merging across paragraphs as it fundamentally alters the structure of the document. There are some CATs that will do this, but with very unstable results. If you want lines separated by a paragraph mark to be in the same segment, replace it with a manual line break before processing in Trados.
People are constantly having problems with MultiTerm. -> That's a JAVA problem, SDL can't do anything about it.
It's hardly SDL's fault that Java is, and always has been, a hideous mess. It's also not unreasonable for SDL to have made MultiTerm heavily dependent on Java given its ubiquity. I believe SDL have said that they intend to do away with MT's Java dependency in a future release, but that's rather a lot of work, so it may be a while.
I have to manually edit every single date in my target text, as the format in German isn't correct -> That's Microsoft's fault!
Well, it isn't really anybody's fault. Microsoft have selected a specific date format for a given language for a reason; most of them are correct (depending on preference), and some of them are not. Incidentally, is it really beyond the realms of possibility to reasonably expect that a corporation the size of Microsoft might have been able to get them all right? In any given language, there can be any number of "accepted" ways of writing the date; Microsoft have chosen one, and the source document doesn't fit the format. That's not anybody's fault; it's a matter of preference. One really has to expect at least some source editing when using any CAT; to expect everything to simply work perfectly without any preparation is unrealistic, especially given the interaction between the CAT tool and other programs on your PC.
As I say, just my 2 cents' worth, but there's always another side to the argument. I'm in no way suggesting that SDL are saints and there is nothing whatever wrong with their software, but to blame them for things that simply aren't their fault seems a trifle unfair.
| | | |
Login to reply/comment 
Translation news related to SDL Trados
