Running crowdin pull after a crowdin upload sources, is not behaving as expected for my YML files.
I’ve used it for JSON in my frontend with no issue.
But for my backend with YML (running on Rails), I’m receiving the wrong language codes at the top of my file. I have specified in the app and all throughout so far successfully what specific language codes I’m using. I also get them downloaded back into file directories with the correct naming.
For instance, when I pull translations for a pt-br language, it renames the locale at the top of the file pt:. Even though it knows to save it into the locale code named directory of pt-br So my I18n is not able to find the correct translated values automatically. I would like to avoid maintaining a ton of inefficient workarounds just to make it work with the incorrect language-dialect codes.
I have now tried both Post-Export and Pre-Export Processors. I could not get any type of response from Pre-Export, and Post-Export seems to get stuck if I am tweaking the code snippet I give it on a previous version. So it is extremely hard to test this and get it right or even know if it is working. Are there any known bugs about this on the Post-Export processor?
Also is there any fix in the works to get this language code to align when exporting this file via CLI? It seems like an unexpected behavior to use different language codes between the file name and the top of the file code.
Potentially there is a caching issue with these scripts? Even after removing the integration, old code is still in effect. Is there any way we can add a way to just clear the cache when this gets changed?
Otherwise, using a custom processor may not work out for this issue I’m having.
