With our organization, we keep reaching and surpassing our source key limit. From the looks of things, we likely only actually use less than 2000 strings, but we apparently have allocated over 13000. Is there a way to reduce our utilized keys?
For example, we likely have deprecated keys - it’s understandable that they may remain in the database and are only marked as deprecated - do these keys count towards our source key limit? Is it possible to “deprecate” our deprecated keys?
We recently had someone in our organization deprecate 9999(+?) keys and added about 1300 - because a few people had shared some access keys early on, it’s hard to determine who performed that work.
In your opinion, if we removed/deleted all of our deprecated keys, and ensured that we uploaded all of the keys we currently have locally, is the risk for deleting the deprecated keys low - would we be losing anything?
There is another filter on the left side above the status icon :-). It’s a bit confusing.
We would love to introduce reporting to be able to find who did what
Having a lot of deprecated keys is normal when you are refactoring localization or changing something critical. Sometimes, it’s even better to have a separate project for it.
Based on your screenshot, some keys are shown several times, so someone likely changed file names or so.
By default, we don’t delete the keys because deprecated ones work as translation memory, and their existing translation can be reused for new keys. And most importantly, sometimes, you can make a mistake, and you don’t want to lose translations - deprecated keys can be easily restored. But if you no longer need them, you are not losing anything.
Hey @vaclav! - when our account is in the “Publishing Disabled” state, is the management UI frozen? For instance, I can see that we’ve deprecated this string (deprecated-string screenshot), but I can’t find the non-deprecated version of it that was probably re-uploaded (published?). If we add more translation keys to our account or if we “remove” enough deprecated strings, will it suddenly appear in the UI as an active string?
No, everything is working even when the publishing is disabled. The only limitation is that changes are not published (not available for download, CLI, CDN, etc.). Import shouldn’t be limited in any way, so I would suspect that you are probably not uploading the key again, or you keep deprecating it repeatedly.
Do you upload your files using CLI? Can you send me your configuration to vaclav@localazy.com for analysis?
You’re right - I looked at the configuration and it looks like the developer is specifically referencing only one particular file now. I’m confirming with them that this is the expected configuration and asking them to clean up all of our old translation files
Some time ago, we added a new feature deprecate for the upload section, which allows deprecating all keys missing from the upload batch across the whole project (which is the same behavior as for the older deprecateMissing option), or, and this may be a potentially good choice for you, keys missing in the touched file only. The second option is perfect when you need both deprecating and partial uploads.
Actually - I have a feeling this group probably went about things the wrong way…
We have 2 Localazy projects, but we have ~3 local projects over here and 2 of them are using the same Localazy project.
For instance:
Localazy Project A
Localazy Project B
Web Project → Localazy Project A
Desktop Project → Localazy Project A
Other Project → Localazy Project B
Here’s what I’m worried about:
If Desktop Project has a Localazy configuration with the deprecateMissing setting, when it runs its upload script, will it “deprecate” any or all strings that the Web Project is using? (unless they share a key?)
I have a feeling we should be creating a third Localazy project so that the Desktop Project can manage its own keys without interfering with the Web Project.
If Localazy projects share the same translation keys, how are keys counted in this case? Do Locallazy Project A and Localazy Project B share keys if they overlap?
Yes, your assumption is correct. If you use deprecateMissing and upload only keys from Desktop Project, keys from Web Project will be deprecated.
Also, please note that keys are not required to be unique in the project - they must be unique within their file.
Technically, you can use deprecate=file, and then uploading files from Desktop Project will not affect files of Web Project.
If your Desktop and Web project share texts, the best solution would be to have a shared file and separated files for each project with its unique texts.
