Auto recognize/replace (custom) codes Thread poster: GabrielaRoman
|
|---|
GabrielaRoman
United Kingdom
Local time: 07:53
English to Romanian
Hi,
Is there a way to make DVX recognize placeholders? For instance, for this block of text:
form.country.BMU = Bermuda
form.country.BOL = Bolivia
form.country.BRA = Brazil
I would like to have dejavu import the text so that form.country.* gets imported as DVX codes so that when exporting, they are preserved.
I was thinking of something along the lines of parsing the original text, replacing all form.country.* with, sa... See more Hi,
Is there a way to make DVX recognize placeholders? For instance, for this block of text:
form.country.BMU = Bermuda
form.country.BOL = Bolivia
form.country.BRA = Brazil
I would like to have dejavu import the text so that form.country.* gets imported as DVX codes so that when exporting, they are preserved.
I was thinking of something along the lines of parsing the original text, replacing all form.country.* with, say, {{form.country.* = }} and then let DVX recognize them and replace them with DVX codes such that the DVX strings would look like:
{1}Bermuda
{2}Bolivia
{3}Brazil
Is there an easier way to achieve that other than writing/hacking a filter?
Kind regards,
Bogdan ▲ Collapse
| | | | | C, C++, Java | Apr 15, 2010 |
Have you tried to import the file using "Java Properties" filter?
Regards!!
| | | | GabrielaRoman
United Kingdom
Local time: 07:53
English to Romanian
TOPIC STARTER | Thanks. Got it working after a bit of tweaking. | Apr 15, 2010 |
Hi,
Many thanks for the tip. I never tried that one.
Unfortunately, I was getting an error when importing using the Java Properties filter and I realized it was because of the dots in the left hand side (the filter expects valid Java-like variable names, meaning word chars only, or [a-zA-Z0-9_] in regular expressions). I replaced all dots in the left hand side (*) with a placeholder __x__ and then it imported fine. Looks pretty good too, DVX then interprets any existin... See more Hi,
Many thanks for the tip. I never tried that one.
Unfortunately, I was getting an error when importing using the Java Properties filter and I realized it was because of the dots in the left hand side (the filter expects valid Java-like variable names, meaning word chars only, or [a-zA-Z0-9_] in regular expressions). I replaced all dots in the left hand side (*) with a placeholder __x__ and then it imported fine. Looks pretty good too, DVX then interprets any existing HTML in the right hand side as well.
(*) replacing the dots only in the left hand side can not be done with a plain search/replace action; you will have to use regexp, or similar. For anyone having a similar issue, I used the following Perl compatible regexp pattern (UltraEdit is the editor I used which knows Perl regexp):
search pattern: ^(\w+)\W(\w+)
replace with: $1__x__$2
You need to run the replace process several times until it reports that no replacements took place any more. This is because one replace process replaces only strings like foo.bar into foo__x__bar but only if foo.bar occurs at the beginning of the line (\w means word char, including _). After translation and export, I just replace back all "__x__" into ".".
Thanks again,
Bogdan.
p.s. I also took the time and built a dtd and xml out of it and then created a dejavu xml filter for the first time ... pretty powerful, I must admit. ▲ Collapse
| | | | | Java Properties filter | Apr 16, 2010 |
Hi Gabriela,
I tried to import a file with the lines you wrote with the Java Properties filter and it imported properly. Which problem with the dots are you getting? Java variables can have dots because the programming object model and DVX should import them without any problem, displaying only the variable values for tranlating.
Anyway, I'm happy to see that you found a workaround to manage the files.
Best regards
| | |
|
|
|
RieM 
United States
Local time: 02:53
English to Japanese
+ ...
Yes, I'm indeed working on Java properties files as I speak, and dots in the Key (left hand side) have never caused any problems with imports as far as I know. They are there almost always anyway...
Gabriela, please allow me to ask Javier in this thread because it is somehow related....
I know a backslash in the key used to be interpreted incorrectly (it is an escape character if used in the Value (right hand side), but it shouldn't be when used as a part of the Key), a... See more Yes, I'm indeed working on Java properties files as I speak, and dots in the Key (left hand side) have never caused any problems with imports as far as I know. They are there almost always anyway...
Gabriela, please allow me to ask Javier in this thread because it is somehow related....
I know a backslash in the key used to be interpreted incorrectly (it is an escape character if used in the Value (right hand side), but it shouldn't be when used as a part of the Key), and DVX imported them incorrectly, using the backslash (instead of the first instance of equal sign in the line) as the end-of-the-key delimiter. I've forgotten to report the bug, because it isn't a big deal. Do you know it has been taken care of?
Rie ▲ Collapse
| | | | GabrielaRoman
United Kingdom
Local time: 07:53
English to Romanian
TOPIC STARTER | Didn't work on the big file. | Apr 16, 2010 |
Hi,
It simply refused to import. I tried with DVX v7.5.503 and v7.5.510 also. The file I'm importing is much bigger, obviously, but it only imported after I replaced the dots. You are right though, a file containing only the 3 lines I posted initially imports just fine ... peculiar.
Thanks again for the tip.
Bogdan
| | | | GabrielaRoman
United Kingdom
Local time: 07:53
English to Romanian
TOPIC STARTER | regexp again | Apr 16, 2010 |
I know a backslash in the key used to be interpreted incorrectly (...)
You probably have plenty of workarounds for that but just in case you're looking for (another) one, you could use the same trick I used above. Replace the backslash with a word-only character sequence, making sure the replacement takes place only in the variable names (regexp is your friend), and then replace back after translation.
Bogdan
| | | | RieM
United States
Local time: 02:53
English to Japanese
+ ...
| in case of backslash, you don't have to replace it | Apr 16, 2010 |
.. because DV does import such strings anyway, and it is very easy, at least for me, to identify them. It will take more time to regrep them back and forth.
It's a simple parsing error DVX commits, and it is also very easy to correct such an bug. As for your "dot" case, I wonder why DV refuses to import it. The size shouldn't matter...
Regards,
Rie
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Auto recognize/replace (custom) codes | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
| | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
