Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Ok, one of the issues, as I thought is that glossaries are meant to be like up to 3 words, very small phrases or words, not entire paragraphs and that's part of the problem. when you get paragraphs that need to be fixed, all you need to do is fix one of the translations and the others will start following suit, they should not be glossary entries.
One of our devs is cleaning your glossary out to see if the problem persists, and I'll let you know the results as soon as we have them.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
Sorry for the delay, the checkup took longer than we expected. So the main issue as we thought is that you had a lot of entries that were super long and ended up truncating the feature (because they took way longer to add than others).
As mentioned, the glossary should not be used as a "translation memory" to handle entire sentences, but at most 3 words (as normal glossaries do).
If you allow me, i'd like to wipe that current glossary, then import the one we have now and then check if the problem continues when exporting it again.
I already have a backup copy of your current glossary, so we can always return to how things were.
Hey,
Is there any other way I can wipe out the glossary term items, export it first and import it again? Can you please provide the steps for it? I want to do it on my development server first.
One more question regarding WPML’s remote (cloud-based) server. I've 3 environments where glossary items are stored, so each environment has glossary terms, and they are stored in the WPML’s remote (cloud-based) server separately. Please confirm. As I've used a different key for each environment. Can you please elaborate more regarding storing the glossary terms in your WPML’s remote (cloud-based) server?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello, you can't really wipe out the glossary unless you delete each element independently.
However I asked our devs to do it for you and this request is definitely a good feature request to improve our glossary set of features.
--------------
Each migration can be either "connected" and share the same things or work independently from each other. it depends on the choice you took when migrating the site.
Now, I personally suggest that if you have 3 sites that are eventually going to be "merged" into any of them, then you connect those sites so you always share credits, translation memory and glossary.
I've seen that there are different translation account IDs in my local environment & dev environment; that means there will be separate databases according to translation IDs in the WPML’s remote (cloud-based) server. Please confirm. One more question regarding the "kind" column in the CSV file. Is it a required column to import the CSV file? Is there any effect on the database to store the CSV without adding the "Kind" column in the CSV file while importing the glossary terms?
---------------------
If there are different translation IDs, then I would prefer to remove the glossary terms from my local environment first.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Can you please send me the translation IDs, it's normal they are different (they are different sites after all) but if they are connected, then that will not matter and I can verify that if you send them over 🙂
If they are not connected, then the glossaries will be independent. if they are connected, then they will be the same among the sites, which seems to be what you want to achieve.
About the Kind Column, for now it's required and it's also required to use the value "name" (other values will end up not showing the terms) but it will stop being required soon after WPML 4.8 is released.
Yes, sure. I want to share with you privately. Please set a private conversation for the translation IDs.
Is there any other plugin/extension for managing the Glossary terms in the WPML?
Hello Alejandro,
I've been following along on this issue. To help clarify, we have one website, but 3 to 4 different instances of it. Local / Development Server / QA Server / Production environment. We will typically clone Production down to QA or Dev. as needed to sync the system for testing new features.
Currently only Production and QA are linked so that they can share credits for translations but we have no plans to promote anything from Dev or QA to production. We will use the credits on QA mostly to test features and practice workflows.
I think we're ok with having the glossaries not connected. This way we can test out uploading a csv on QA without impacting Production's content.
Regarding: "However I asked our devs to do it for you and this request is definitely a good feature request to improve our glossary set of features."
Would it be possible to clear the glossary associated with hidden link so that we can test uploading a corrected CSV. To confirm, it looks as though the Kind column should exist all with "name" values in them? Additionally we'd need to clean out the CSV of any rows that contain too much data. Is there a character count for the glossary terms that we can check against? 2-3 words can vary in character count, so I'd like to be more precise.
Also to clarify on Vipul's "Is there any other plugin/extension for managing the Glossary terms in the WPML?"
We'd like to know what particular plugin powers the "Glossary" feature, I imagine it is WPML Multilingual CMS, based on your comment of version 4.8? We want to make note that when we update the WPML plugins that we regression check that the Glossary terms are not reverted or corrupted.
When the Kind column is removed in 4.8 will we need to re-import all our glossary terms again?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Before we move forward with this I need to ask you something. When I presented the case to our developers they mentioned that the first thing they noticed is that the glossary you presented was full of terms that are not meant to be a glossary entry. they trimmed it down and the result is found here: hidden link this list was made by our devs and linguists.
Now, what we want to understand is why you have a glossary with so many other entries that should either be translation memory or well just translated normally.
Do you add the glossaries AFTER translating or before doing so? I'm sure that if you added the entries there was a reason for it and we wanted to understand it because turns out that part of the problem while importing/exporting/updating has to do with the amount of entries and well, we want to understand first why the entry list here was so big. so we can then understand what suggestion to give you in general for the glossary and workflows to use to avoid issues.
Hi Alejandro - We had TM's from former translation partners as well as lists of words and phrases that are commonly used in our Product Manuals that we imported well before we ever started translating anything - think February time-frame. We have only imported 1 glossary csv since we moved to this system in mid-March and it was a list of EN to ZH-HANS terms supplied by our Marketing team in China approx. 6-8 weeks ago. In fact it was our China team asking us for the entire Glossary so they could translate that lead to me finding this issue.
As to why we have them in there, we were told by the salesperson to import our TMs so we did. We were not told of any limitations or anything really except to download the sample file and follow it, so we did. In fact there was a team of 3 people who spent hours and hours getting everything into the correct format so it's pretty frustrating to now see most of that work gone and to now find out that it was wasted time and/or hasn't been helping us at all. We brought most of the translated content over from our old CMS and created the pages during import so years of translations are only available in those old TMs that we used for the imports to Glossary and not in WPML so it made sense to us to import those TMs so that WPML could understand our terminology and use our preferences in future translations, easing the workload of our Regional Teams. Are you now saying we're basically going to have to start from scratch?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
I see, thanks for the inforamtion and I totally understand that what happened here was not just unfortunate but super frustrating as well so I'll try to find a suitable solution for you.
We're hard at work and have been hearing the feedback from similar people affected of this and we're already making changes to accomodate and avoid this problem.
For now I ask you: can you check the glossary I sent and tell me why and IF it could not work for you, this way we can learn and also try to find a solution that doesn't require you to work super hard again or lose any of your work.
If there are phrases that should be translation memory or that does create issues, maybe you can send them to us and I can send it to our devs and see if we can find a suitable solution for you.
------------------
By the way if you use DeepL, please be aware that DeepL takes the glossary as a "suggestion" sometimes so it could translate it if it sees that the translation would not make sense otherwise. it doesn't happen super often but it happens sometimes.
