Proposal: get language list from Crowdin API about ota-client-js HOT 8 CLOSED

Also, we should think about some caching for the response to reduce the number of API calls (languages are not changed so often). Maybe, you will have some ideas?

Yeah I was thinking of using that endpoint but only after the language list is needed, as we would not be able to fetch it upon instantiating the class. This way you could have a languagesCache private prop and only fetch if that prop is null.
My issue with this and the reason I didn't make a PR to begin with is that this would require pretty much all functions in exportPattern.ts to be moved to the class so that they could access the property, which I would like to know if you think is fine to do or if there's another alternative.

from ota-client-js.

@yevheniyJ @ImRodry we can start with using only the regular Crowdin API and then implement Crowdin Enterprise API support. The difference in languages is small and in most cases, it will work well.

We are considering the possibility to include the organization name into the distribution manifest.json and then it can be fetched to make a corresponding API request using the Crowdin Enterprise API endpoint.

Anyway, from my perspective, I don't see anything wrong in manually passing the organization name to OTA Client except a case when it can be configured incorrectly as @yevheniyJ said.

from ota-client-js.

I have most of the functionality implemented in my fork, I just can't figure out a good way to add tests to exportPattern.spec.ts as I have made the functions in there depend on the languages array that comes from the client like was suggested above. Should I create a mock client in that file or is there a better approach? I'm not too familiar with these tests so I'm slightly confused
Turns out I was overcomplicating it and just needed to create a fake languages array for the test, will PR now

from ota-client-js.

Hi @ImRodry!

Thanks a lot for your suggestion. Discussed it with the team and from our perspective, the best way will be to make an API call and fetch the languages list.

You can use this API method - https://support.crowdin.com/api/v2/#operation/api.languages.getMany

Also, we should think about some caching for the response to reduce the number of API calls (languages are not changed so often). Maybe, you will have some ideas?

from ota-client-js.

We do have already some kind of caching mechanism for manifest and I think we can implmenet it in the same way. Check the manifest getter method. Regarding the changes in exportPattern.ts I think what we can do is to simply extend the each method to accept the list of languages. Therefore we can keep all functions in the current place. What is still not yet clear is how to get languages for Enterprise usage. The endpoint is then dynamic and organization is a part of it. And with having only hash it is not possible to determine what url needs to be called for list of languages. @andrii-bodnar Do you think we can still use v2 API endpoint for Enterprise usecases as well?

from ota-client-js.

It seems like the Enterprise API needs the name of the organization, however, it does not need an API token. The only difference from the regular crowdin endpoint to the enterprise one is that some languages are missing and the locales for lolcat and pirate english are different. Perhaps they could be updated to match? Either way I believe it'd be safer to stick with the regular API as we don't need the org name and it is more complete, however we can also add an option to the client for the organization name which, when provided, will fetch the crowdin enterprise API

from ota-client-js.

This might be an option but the only concern that I have here is that users can configure client incorrectly (e.g. specifying organization but they are actually not using the enterprise version). We at least should write it down in the documentation.

from ota-client-js.

I'll make sure to include proper documentation as well as a note in the README when I make the PR 👍🏻

from ota-client-js.