-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translation keys not in Sync with Loco | Duplicated from Loco #189
Comments
@Nyholm I know it's a bit of a long read - but if you could just let me know which way I should be going according to you vision of this bundle family I'll be happy to work on it and submit a PR :) |
It seams to be something strange when downloading from Loco. Check the |
I have same problem. I have not been able to work with Loco. Sources changed, duplicated translations, copied all translations in all domain files... |
Hello. I found the problem, it is indeed the index key as @Nyholm was saying. For the scenarios we use "source" as the id for the translation we need to tell Loco that "index" is "text" instead of "id" Basically changes are:
More info here: |
@dkozickis will the changes in https://github.com/php-translation/loco-adapter master fix your problem? |
@joshlopes @Nyholm thank you guys for your work! The problem still persists, but it boils down to how Loco works. When Loco gets below XLIFF with "index" set to "text", is still uses Interestingly - if we remove <?xml version="1.0" encoding="utf-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="en">
<file id="messages.en">
<unit id="X8pvpvu">
<notes>
<note category="file-source" priority="1">templates/base.html.twig:10</note>
<note category="state" priority="1">new</note>
</notes>
<segment>
<source>test_translate</source>
<target></target>
</segment>
</unit>
</file>
</xliff> @Nyholm do you know if this is a bug or a feature of Loco? :) You seem to have a lot of experience working with them. If this is a feature - do we modify Loco adapter to drop |
@dkozickis I'm currently using this on my projects. It's working as expected. Delete everything on loco and sync again may help, as it may be confused. Also if your id's are already there LOCO will use ids i think! So you will need to delete everything and sync again. |
@joshlopes are you using "text" as "index"? I will try deleting and making a new project in Loco, thank you 👍 |
@dkozickis yes i'm using text which basically tells Loco that |
Hi ! @dkozickis you said that you have overridden some Xliff Dumpers. Do you still do that ? What is your current workflow when creating new keys to translate ? |
Hi all. Sorry to barge in here, and I know it's a bit late. Your original issue here is a "fault" at Loco's end, but there is a reason for it (and a fix). Loco has/had an issue with Symonfy's implementation of XLIFF 2.0 which Tobias kindly fixed. XLIFF 2 files must have the translation key in the That fallback may seem like a bug, except that Loco's XLIFF parser is not specific to Symfony. Although XLIFF is great for readability and metadata, it also gives platforms the flexibility to go their own way. (e.g. Xcode uses the If you have any queries relating to the Loco API, as opposed to library code, feel free to email me directly at support at localise dot biz. |
Hi, I just retry to reproduce this bug with the given reproducer on the first message here. It does not happen anymore. Could you confirm @dkozickis? If yes, I will close the issue |
Hi!
I have an issue with translation keys going in and out of Loco and getting duplicated a lot.
I've traced this down (I think), and wanted your opinion on what's the correct way forward fixing it.
First of all - here's a reproducer - https://github.com/dkozickis/translation-issue-reproducer
Just change the Loco AP key in
config/packages/php_translation.yml
templates/base.html.twig
contains the example stringRun:
php bin/console translation:extract
Below is generated, as you can see translation id is
X8pvpvu
:First
php bin/console translate:sync app
gives expected results, string goes into Loco.Second
php bin/console translate:sync app
gives unexpected results:As you see, we now have a duplicate with
source
same as original stringkey
.There are couple things that cause this.
sync
command runs following:symfony-bundle/Service/StorageService.php
Lines 92 to 93 in d38e646
Meaning that during sync, with Loco adapter, first all data from Loco will be downloaded, then all data will be uploaded to Loco.
Given that we've already done first sync, second sync will produce following XLIFF result from Loco:
For whatever the magic reason, Loco have put
<unit id=>
from initialexract
into<source>
At this point, Xliff Dumper (part of
symfony-storage
lib) grabs the<source>
from Loco dump, and generates a new<unit id=>
, thus we arrive to unexpected results mentioned above.After that data is uploaded to Loco, and the new key is now reimported into Loco, essentially duplicating everything, after every
translate:sync
My current workaround for this is to have custom Xliff Dumper overriding standard
symfony/translation
Xliff Dumper (works duringtranslate:extract
) and custom fork ofsymfony-storage
overring Xliff Dumper there (duplication insymfony-storage
). My Xliff Dumpers just take<source>
as<unit id>
, thus, when I load into Loco, I load with the samekey
assource
, and when I download from Loco, I get<source>
same as existing<key>
in existing translation files, this helps me avoid duplication.Hope my description was clear...
What I want to know:
Thank you!
The text was updated successfully, but these errors were encountered: