You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm relatively new to Tolgee, found it little over a week back and I've successfully used the web interface to translate all of the strings in my hybrid mobile app. this morning I tried to see if I could integrate the CLI tool with my workspace, as this seems to be the most efficient way to handle synchronising the list of "translation keys" in my local project with the associated Tolgee project. but this is where I'm starting to run into some issues..
for context, my workspace is a Nx monorepo with multiple Angular-based and Capacitor-powered hybrid mobile applications.
the application I'm working with currently has 360 keys and 2 languages, which does still fit within the 1000 string limit of the free tier. so I created a config file at ./apps/my-app/.tolgeerc.json (file extension simply to ensure my IDE uses the appropriate syntax highlighting), and set my push and pull paths appropriately (./src/assets/i18n/ relative to my .tolgeerc.json file, because that's where Transloco looks for the files).
first point: I then tried to run tolgee -c ./apps/my-app/.tolgeerc.json push, since my local translation files did have a few changes (4 keys added, 2 keys removed), but at the "importing" step I got the message Invalid request data [status: 400, code: plan_translation_limit_exceeded].
that message makes me think the CLI tool is checking how many strings I have available to me, seeing that it's less than it's about to try uploading, and then not going any further. or am I misunderstanding the meaning of this error code?
second point: I then tried to run tolgee -c ./apps/my-app/.tolgeerc.json compare, hoping that might give a little more context as to what the Tolgee CLI tool was seeing from the local and remote sources, but this gave me the message No files were matched for extraction.
did I configure my project incorrectly for this? I'm not trying to use any of the automated extraction features, and I do not intend to. so I'm not sure what I'm missing here...
third point: I then made a backup of my local files and ran tolgee -c ./apps/my-app/.tolgeerc.json pull, which successfully downloaded my en.json and de.json files from Tolgee to the correct place locally, but using the traditional "nested JSON" structure, not the "Flat JSON" structure that I get when exporting through the web UI.
I do a string search in my workspace when looking for translation keys, which helps to keep consistency between my translation and markup files. so can the CLI tool (currently on 2.1.5) not export translations as "flat JSON"? is this something that is going to be added at some point?
note: if you need any more details regarding my workspace configuration, please don't hesitate to ask. if I can get this platform to fit in my workflow, even if that means adjusting my workflow, there is a very good chance I can convince my employer to sign us up for a paid subscription, where we will be managing a few thousand translation keys across multiple hybrid-mobile, desktop, and web interfaces.. just need to work out a few teething issues first.
The error message is coming from backend, and it indicates that the import would exceed the 1000 strings limit (which is weird since you shouldn't have more then 1000). You can try to import each language separately and see if it increases number of strings, or use the manual import in the UI, that might be a bit more user friendly to debug this.
The compare command extracts keys from your code and compares them to tolgee platform (it's not working with your json translations), so you can see, if you have any unused ones etc. We don't yet have extractor for angular, so it will not work for you currently (although we want to fix this in near future).
Ah, yeah, you are right about the delimiter. No the sync command also works with keys extracted from code, so that is something else.
The tolgee CLI doesn't really check number of strings in your project, it simply tries to import the files to the platform and the platform rejects it, if it goes above your limit.
So what I was suggesting was to try to import them manually throught the platform UI (which is essentially the same thing) and see if there is some problem (like it's trying to create new keys instead of updating existing ones).
right... I think I understand, conflict resolution is all done server-side, hence the existence of the --force-mode CLI flag when pushing translations.
just discovered something interesting though: if I run tolgee push from my Windows 11 Pro environment, I get the aforementioned plan_translation_limit_exceeded error response, but the same command with the same files from my Zorin OS (Debian based) environment works correctly.
I'll do a little more testing with verbose output and log an issue in the CLI project shortly.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
howdy good people,
I'm relatively new to Tolgee, found it little over a week back and I've successfully used the web interface to translate all of the strings in my hybrid mobile app. this morning I tried to see if I could integrate the CLI tool with my workspace, as this seems to be the most efficient way to handle synchronising the list of "translation keys" in my local project with the associated Tolgee project. but this is where I'm starting to run into some issues..
for context, my workspace is a Nx monorepo with multiple Angular-based and Capacitor-powered hybrid mobile applications.
the application I'm working with currently has 360 keys and 2 languages, which does still fit within the 1000 string limit of the free tier. so I created a config file at
./apps/my-app/.tolgeerc.json(file extension simply to ensure my IDE uses the appropriate syntax highlighting), and set mypushandpullpaths appropriately (./src/assets/i18n/relative to my.tolgeerc.jsonfile, because that's where Transloco looks for the files).first point: I then tried to run
tolgee -c ./apps/my-app/.tolgeerc.json push, since my local translation files did have a few changes (4 keys added, 2 keys removed), but at the "importing" step I got the messageInvalid request data [status: 400, code: plan_translation_limit_exceeded].that message makes me think the CLI tool is checking how many strings I have available to me, seeing that it's less than it's about to try uploading, and then not going any further. or am I misunderstanding the meaning of this error code?
second point: I then tried to run
tolgee -c ./apps/my-app/.tolgeerc.json compare, hoping that might give a little more context as to what the Tolgee CLI tool was seeing from the local and remote sources, but this gave me the messageNo files were matched for extraction.did I configure my project incorrectly for this? I'm not trying to use any of the automated extraction features, and I do not intend to. so I'm not sure what I'm missing here...
third point: I then made a backup of my local files and ran
tolgee -c ./apps/my-app/.tolgeerc.json pull, which successfully downloaded myen.jsonandde.jsonfiles from Tolgee to the correct place locally, but using the traditional "nested JSON" structure, not the "Flat JSON" structure that I get when exporting through the web UI.I do a string search in my workspace when looking for translation keys, which helps to keep consistency between my translation and markup files. so can the CLI tool (currently on
2.1.5) not export translations as "flat JSON"? is this something that is going to be added at some point?note: if you need any more details regarding my workspace configuration, please don't hesitate to ask. if I can get this platform to fit in my workflow, even if that means adjusting my workflow, there is a very good chance I can convince my employer to sign us up for a paid subscription, where we will be managing a few thousand translation keys across multiple hybrid-mobile, desktop, and web interfaces.. just need to work out a few teething issues first.
All reactions