Define state of the unit on create via API

[antonkomarev]

Describe the problem

It would be greate to have a way to define state of the unit on creation via an API.
If we will do it in 2 steps (1 — create unit, 2 — patch unit state), there may be an issue with data consistency. For example 1st request is done, but on second there will be network issue, or requester server has died unexpectedly.

POST /api/translations/(string: project)/(string: component)/(string: language)/units/

{
    "key": "example_key",
    "value": ["Example translation"]
}

Describe the solution you'd like

POST /api/translations/(string: project)/(string: component)/(string: language)/units/

{
    "key": "example_key",
    "value": ["Example translation"],
    "state": 10 // Needs editing
}

Describe alternatives you've considered

No response

Screenshots

No response

Additional context

No response

[github-actions]

This issue seems to be a good fit for newbie contributors. You are welcome to contribute to Weblate! Don't hesitate to ask any questions you would have while implementing this.

You can learn about how to get started in our contributors documentation.

[scott-gorman]

Hey, i'd like to work on this!

[nijel]

You are welcome. In case you need any guidance don't hesitate to ask.

[antonkomarev]

@scott-gorman any progress on it?

[rhofer]

It would also be good to extend the API for GETting a translation. This together with writing POST the state would be great for roundtrip needs.

Example:
We need to boldly work on translation keys. Therefore, old key with old value should go to new key with old value. Just doing this in the connected repository is working, but weblate is loosing the previous translation state. Therefore, we would be happy to use the API in away so that

1. GET (all) units with its state (-> do it with API)
2. copy over and create new keys with old values (-> could be done in connected repo (as-is))
3. POST (all) units' former states forward to the new keys (with old values) (-> do it with API)
4. removing old key value pairs (-> could be done in connected repo (as-is))

@scott-gorman could you consider this when workin on API extension?

[rhofer]

@nijel with my example described in #7601 (comment) above, this only addresses "meta data" as the state. But when doing such operations as mentioned, it would be good to act on further "meta data" as suggestions and comments , so that potentially API would allow to act on them as well.

Would this fit to this issue or shall I write a new one?

[nijel]

@rhofer Please open separate issue for each of these.

[antonkomarev]

@nijel thank you!

[github-actions]

Thank you for your report; the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.