Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build REST API for remote Translation Requests #6

Open
samuelowino opened this issue Apr 4, 2024 · 6 comments
Open

Build REST API for remote Translation Requests #6

samuelowino opened this issue Apr 4, 2024 · 6 comments

Comments

@samuelowino
Copy link
Owner

  1. Define Endpoints:

    • Create endpoints to handle translation requests, such as /translate.
    • Use HTTP methods like POST to submit translation requests and GET to retrieve translated content.
  2. Request Payload:

    • Define the structure of the request payload, which may include the text to be translated, source language, target language, and any additional parameters.
  3. Authentication and Authorization:

    • Implement authentication mechanisms to ensure that only authorized users can access the translation API.
    • Use API keys, tokens, or OAuth for secure access.
  4. Translation Service Integration:

    • Integrate with a translation service or library that provides translation capabilities.
    • Utilize popular translation APIs such as Google Cloud Translation, Microsoft Translator, or open-source libraries like OpenNMT.
  5. Error Handling:

    • Define error responses for cases such as invalid requests, authentication failures, or translation service errors.
    • Use appropriate HTTP status codes and error messages to communicate issues to the client.
  6. Response Format:

    • Structure the response to include the translated text, any metadata, and status indicators.
    • Return the translated content in a standardized format, such as JSON or XML.
  7. Localization:

    • Support localization of error messages and response content to accommodate clients in different regions.
  8. Testing and Documentation:

    • Write comprehensive documentation for the API, including details on endpoint usage, request payloads, and response formats.
    • Perform thorough testing of the API using tools like Postman or curl to ensure functionality and reliability.
  9. Security:

    • Implement secure communication using HTTPS to protect data transmission.
    • Consider data privacy and compliance with regulations such as GDPR when handling translation requests.
  10. Scalability and Performance:

  • Design the API to handle a high volume of translation requests efficiently.
  • Consider caching translated content and optimizing response times for improved performance.
@mwangidennis1
Copy link
Contributor

Can i implement this together with issue 4 and 5

@samuelowino
Copy link
Owner Author

Yes of course

@mwangidennis1
Copy link
Contributor

for For Freighting localized Strings... there is no spec and the code gives me an impression i need one since my localized strings are saved in the target folder but the Freighting expects i load the classes from a class path eg /home/mwangi/mobile-translate/src/main/resources then it tries to look for a file eg "files/pl.xml" but they are not there so it will always return a null(which is not handled ) by the caller here is the method in the IOUtils.class ignore the logs public static InputStream loadResourceFileUrl(String fileName){
//logger.info("HERE IS THE FILE I GET: " + fileName);
//logger.info("WHAT IS THIS " + IOUtils.class.getClassLoader().getResourceAsStream("files/" + fileName));
return IOUtils.class.getClassLoader().getResourceAsStream("files/" + fileName);
}

@samuelowino
Copy link
Owner Author

Freighter is designed to copy translated text into an Android Studio project. It requires the translated files to be located in the src/main/../files directory. You can write additional code to move the translated XML files to the res directory and read from there, or simply paste sample files for your own testing.

@mwangidennis1
Copy link
Contributor

since i am not doing this for production reasons and self assigned keys ( generally only good for testing since the CA is not verifiable ) i would like to skip spec 9 and also the google translation api is not free so i will leave the way it is on the README (not doing this for production) i would also like to skip spec 4 if thats`s okay i can continue with the rest api design

@samuelowino
Copy link
Owner Author

Yes, please proceed without it. I can assist with any tests that require a Google Cloud account. Our goal is to create a straightforward interface where pre-translated Android strings.xml or iOS Localizable.strings files can be submitted, and we receive a list of translated versions in the available locales.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants