this API is rest(ful) API the translation server provides to other applications. as long API is followed it an be replaced by any other server using whatever technology.

all API calls needs a http header 'X-Service-Token' which identifies the application on which the rest action will operate.

X-Service-Token: long_token_configured_to_the_system

as this is a storage for gettext the translation-key is the default when there s no translation stored. these translation-keys can be sent (update request) to server which stores them into the system. they can be rolled back (rollback request) which resets the system to the state before the first update or last commit. or you commit the last changes.

all the request are HTTP PUT since they change the set of keys for the selected application.

the request needs to go to the url

http://<host>/translation_keys

the payload for the request as yaml (mime: application/x-yaml or text/yaml)

---
translation_keys:
- translation system
- update translation
- use default

or as json (mime: application/json )

{"translation_keys":["translation system1","update translation","use default"]}

or as xml (mime: application/xml )

<translation-keys>
  <translation-key>translation system</translation-key>
  <translation-key>update translation</translation-key>
  <translation-key>use default</translation-key>
</translation-keys>

or as query parameters

?translation_keys=translation%20system&translation_keys=update%20translation&translation_keys=use%20default

the response payload will be (i.e. as yaml for easy reading)

---
- translation_key:
    id: 1
    name: translation system
    updated_at: '2012-12-10 17:57:43.000000+0000'
- translation_key:
    id: 45
    name: update translation
    updated_at: '2012-12-11 04:30:27.64521042307+0000'
- translation_key:
    id: 46
    name: use default
    updated_at: '2012-12-11 04:30:20.000000+0000'

the date-format is (using notation from unix date command) which always uses UT timezone

 %Y-%m-%d %H:%m:%S.%N%z

content negotiation takes place via http headers for the request (i.e. json)

Content-Type: application/json

and for the desired response use (i.e. xml)

Accept: application/xml

the PUT request needs to go to the url respectively

http://<host>/translation_keys/rollback
http://<host>/translation_keys/commit

or for retrieval a GET request goes to

http://<host>/translation_keys

the response is identical to the update request, dito response content type.

• translation_keys
• locales
• domains (not part of the translation server)
• translations

all retrieval uses GET with following urls

http://<host>/locales/last_changes?updated_at=<date of last local entry>
http://<host>/translation_keys/committed_last_changes?updated_at=<date of last local entry>
http://<host>/translation_keys/uncommitted_last_changes?updated_at=<date of last local entry>
http://<host>/translations/committed_last_changes?updated_at=<date of last local entry>
http://<host>/translations/uncommitted_last_changes?updated_at=<date of last local entry>

where the date of last local entry has the format

%Y-%m-%d %H:%m:%S.%N%z
%Y-%m-%d %H:%m:%S.%N

example without timezone which implies UTC

2000-01-01 01:01:01.000000

the committed urls are meant for production and the uncommitted urls for development and refer to the update/rollback/commit part from above.

---
- translation:
    text: some translations of key with id=1 and for locale with id=2 and default domain
    updated_at: '2012-12-10 17:57:43.000000+0000'
    translation_key_id: 1
    locale_id: 2
    domain_id: 

---
- locale:
    id: 2
    code: de
    updated_at: '2012-12-10 17:57:43.000000+0000'

---
- translation_key:
    id: 1
    name: translation system
    updated_at: '2012-12-10 17:57:43.000000+0000'

the current rails application might just use '2012-12-10T17:57:43.000000+0000' instead '2012-12-10 17:57:43.000000+0000' depending on the format it produces (maybe there is a way to configure uniformly).

and the database in general does not store smaller time units then seconds, so the nanoseconds part is most likely always be .000000.