Unit Instance

HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlescommitters-guide_index/en/?format=api",
    "source": [
        "Historical practice has varied, though some of the variance is by field.  For example, MFCs that are relevant to a PR generally include the PR field in the MFC so that MFC commits are included in the bug tracker's audit trail.  Other fields are less clear.  For example, Phabricator shows the diff of the last commit tagged to a review, so including Phabricator URLs replaces the main commit with the landed commits.  The list of reviewers is also not clear.  If a reviewer has approved a change to `main`, does that mean they have approved the MFC commit? Is that true if it's identical code only, or with merely trivial rework? It's clearly not true for more extensive reworks.  Even for identical code what if the commit doesn't conflict but introduces an ABI change? A reviewer may have ok'd a commit for `main` due to the ABI breakage but may not approve of merging the same commit as-is.  One will have to use one's best judgment until clear guidelines can be agreed upon."
    ],
    "previous_source": "",
    "target": [
        "Historical practice has varied, though some of the variance is by field.  For example, MFCs that are relevant to a PR generally include the PR field in the MFC so that MFC commits are included in the bug tracker's audit trail.  Other fields are less clear.  For example, Phabricator shows the diff of the last commit tagged to a review, so including Phabricator URLs replaces the main commit with the landed commits.  The list of reviewers is also not clear.  If a reviewer has approved a change to `main`, does that mean they have approved the MFC commit? Is that true if it's identical code only, or with merely trivial rework? It's clearly not true for more extensive reworks.  Even for identical code what if the commit doesn't conflict but introduces an ABI change? A reviewer may have ok'd a commit for `main` due to the ABI breakage but may not approve of merging the same commit as-is.  One will have to use one's best judgment until clear guidelines can be agreed upon."
    ],
    "id_hash": -5947244495957883788,
    "content_hash": -5947244495957883788,
    "location": "documentation/content/en/articles/committers-guide/_index.adoc:1067",
    "context": "",
    "note": "type: Plain text",
    "flags": "",
    "labels": [],
    "state": 100,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 317,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 173,
    "source_unit": "https://translate-dev.freebsd.org/api/units/1575138/?format=api",
    "priority": 100,
    "id": 1575138,
    "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlescommitters-guide_index/en/?checksum=2d7724a40a088474",
    "url": "https://translate-dev.freebsd.org/api/units/1575138/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2023-05-21T18:26:58.942172Z"
}