Repetitions won't import back into iLocalize

[Jose Palomares]

Hi all,

I have been holding yet another doubt regarding how iLocalize works.
Whenever I export strings for translation into a XLIFF file, any
repeated source text goes in the file normally. However, at the time
of reimporting those strings, only the first instance of each source
string would be reimported, leaving me with the task to populate them
manually. Doing so is not only cumbersome, but also involves the risk
of missing different translations for the same source text, creating
all sorts of inconsistencies, gender/number mismatches, etc.

Do any/all of you experience the same issue? May I be doing something
wrong?

Thanks so much
Jose

[Jose Palomares]

Any ideas, someone?

Jose

[Karl-Johan Norén]

2 mar 2012 kl. 12.22 skrev Jose Palomares:

> On 28 feb, 12:17, Jose Palomares <josepaloma...@gmail.com> wrote:
>> I have been holding yet another doubt regarding how iLocalize works.
>> Whenever I export strings for translation into a XLIFF file, any
>> repeated source text goes in the file normally. However, at the time
>> of reimporting those strings, only the first instance of each source
>> string would be reimported, leaving me with the task to populate them
>> manually.

Sorry, no. Experienced the same issue with import from a .strings file.

--
Karl-Johan Norén karl-...@norensoversattningar.se
Noréns översättningar http://www.norensoversattningar.se
Box 334 070-324 92 05
SE-331 23 Värnamo +46(0)70-324 92 05
SWEDEN

[Jose Palomares]

Thanks, Karl-Johan. Me too. Neither XLIFF nor .strings re-import would
include repetitions.

That's really bad news :(

Jose

[Jean Bovet]

Sorry for my late reply (we had a new baby last week so my schedule is a bit up-side-down). To answer your question: if you have several identical strings (where the base string is the same), you'll face an issue because a .strings file has no way to distinguish between two identical strings. For XLIFF, it might be possible to use the id attribute of each entry to identify each string without collision but there are other problems (such as what you can put in the id attribute which doesn't allow all the characters from the key). Do you have a lot of repetition in your files? I'm curious about how frequent this scenario is happening.

Anyone has some experience with the XLIFF format in that regards? Is the id attribute the best place to identify uniquely each entry?

Jean

> --
> You received this message because you are subscribed to the Google Groups "iLocalize" group.
> To post to this group, send email to iloc...@googlegroups.com.
> To unsubscribe from this group, send email to ilocalize+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ilocalize?hl=en.
>

[Ernesto Gómez]

Congratulations, Jean,

Ernesto

[Jose Palomares]

Thank you for replying, all considering :)

In my case repetitions are really common scenario. For instance,
"Edit" would appear on almost any application, one referring to the
"Edit" menu on MainMenu, and some other as a button somewhere. The
problem is that it would require different translations for each case,
so auto-propagation is not an option.

I get to work a lot with XLIFF and I think you can safely use the id
attribute to include whatever unique identifier you want to use,
either numeric or alphanumeric, as long as it doesn't contain spaces.
Sometimes a numeric series would do, but the best thing in my opinion
is to include the source key string as id attribute (so you can use it
as context reference for the translation). By combining the id and
some info about the source file (such as the '<file>' element), you
can cover pretty much all the basic details to know what are you
translating and where.
And if you want to combine numeric id and key string, you can code the
later through the "resname" attribute (again, no spaces).

Hope this makes sense.

Best,

Jose

[Michel Jean-François]

Hi Jean,

I did a project fro our Artlantis Software 4.0, then export to my outside translator a glossary in .xlif format, but when I tried to "reimport" the translated items to my project, I Localize 4.1 failed to read the .XLIF file, it's grayed.
I did a test with a .TMX file, and the TMX file was readable when I used "Translate Using External String" or control-click "Update Strings". What is wrong in my process?
Should I need to convert first XLIF to TMX?
Did I miss something?

Thank you for your answer. I remember I did that in 3.x version or may be with 4.0???

Michel Jean-François
Responsable Assurance Qualité Logiciel
Software Quality Assurance Manager

ABVENT
58, rue Saint-Lazare
75009 PARIS
Tél. : (33) 01 53 01 05 05
Fax : (33) 01 53 01 05 00
web site : www.abvent.com

-------------------------------
Ce message électronique et tous les fichiers attachés qu'il contient sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle
ils sont adressés. Si vous avez reçu ce message par erreur, merci de le retourner à son émetteur. Les idées et opinions présentées dans ce message
sont celles de son auteur, et ne représentent pas nécessairement celles du Groupe Abvent ou d'une quelconque de ses filiales. La publication, l'usage,
la distribution, l'impression ou la copie non autorisée de ce message et des attachements qu'il contient sont strictement interdits.

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual to whom it is addressed. If you have
received this email in error please send it back to the person that sent it to you.
Any views or opinions presented are solely those of its author and do not necessarily represent those of Abvent Group or any of its subsidiary
companies. Unauthorized publication, use, dissemination, forwarding, printing or copying of this email and its associated attachments is strictly
prohibited.

[Jean-Pierre Kuypers]

On 21 mai, 10:39, Michel Jean-François <m...@abvent.fr> wrote:
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual to whom it is addressed. If you have
> received this email in error please send it back to the person that sent it to you.
> Any views or opinions presented are solely those of its author and do not necessarily represent those of Abvent Group or any of its subsidiary
> companies. Unauthorized publication, use, dissemination, forwarding, printing or copying of this email and its associated attachments is strictly
> prohibited.

So a text on a Google group is very judicious, isn't it?
For French speaking people who like so disclaimers, read
<http://www.journaldunet.com/juridique/juridique020522.shtml>

[Jean Bovet]

It should read the xlif file... can you send it to my privately so I can have a look?

Thanks,

Jean