2

For the SE API, the endpoints dealing with flags (e.g. /questions/{id}/flags/options) return the flag_option type. However, the option_id values are explicitly stated as being unstable, but it's necessary to determine the option_id that is assigned to the flag in order to use any of the /flags/add endpoints.

To determine which option_id to use, some other property of the flag_option must be checked to see if it matches the flag type desired. Unfortunately, the title and description are localized, so are not the same across all sites.

What are the localized values that are used for the title, and on which sites are they localized?

Improve this question
5
  • We really need to push for this feature request, rather than trying to stand on the shifting sands of whatever today's phrase translation is.
    – Brock Adams
    Commented Aug 8, 2018 at 21:38
  • @BrockAdams I strongly agree with that, but it's, at best, 6–8 somethings from now. I consider having to match the localized strings to a list hard-coded in the app/script to be a kludge. However, it's the currently available path to functionality when you're not displaying the title/` dialog_title` and description to the user for selection. This Q&A is here because I was frustrated by not finding this information anywhere, other than in the responses from the SE API. My hope is that these might save someone the time of determining what all the title strings are.
    – Makyen
    Commented Aug 8, 2018 at 22:01
  • Admirable, but there is a possibly better kludge IMO. That is: the most important/core flag id's -- though not stable from release to release -- are stable across sites for a given release. That is, for a given "release"/build of StackExchange, the spam flag has a fixed set of values (or a single common value), etc
    – Brock Adams
    Commented Aug 8, 2018 at 22:29
  • @BrockAdams While the option_id numbers may be stable over a considerable time, the documentation explicitly states that their stability should not be relied upon. As Shog9 has said, and I agree with, doing a match to the text of the title is more likely to fail-safe than using the numeric option_id.
    – Makyen
    Commented Aug 9, 2018 at 0:09
  • Not if you verify that id as needed (which would be: (1) rarely, (2) only upon build changes, and (automatable)). That guards against both Id and translation changes. I may write up this approach, but I want to make a tool for it first and both are low priority for me.
    – Brock Adams
    Commented Aug 9, 2018 at 0:29

1 Answer 1

Reset to default
2

The values for the question and answer flag_option title properties, which I've determined experimentally, are:

const flagTypes = {
    /* Localizations:
     *   English (not localized)
     *   Japanese: ja.stackoverflow.com
     *   Spanish: es.stackoverflow.com
     *   Portuguese: pt.stackoverflow.com
     *   Russian: ru.stackoverflow.com & rus.stackexchange.com (Русский язык)
     */
    spam: [
        'spam', // English & Portuguese
        'スパム', // Japanese
        'contenido no deseado', // Spanish
        'спам', // Russian
    ],
    rude: [
        'rude or abusive', // English
        '失礼又は暴言', // Japanese
        'rude ou abusivo', // Portuguese
        'невежливый или оскорбительный', // Russian
        'irrespetuoso o abusivo', // Spanish
    ],
    naa: [
        'not an answer', // English
        '回答になっていません', // Japanese
        'não é uma resposta', // Portuguese
        'не является ответом', // Russian
        'no es una respuesta', // Spanish
    ],
    vlq: [
        'very low quality', // English
        '品質が低すぎる', // Japanese
        'qualidade muito baixa', // Portuguese
        'необходимо удалить из-за проблем с качеством', // Russian
        'muy baja calidad', // Spanish
    ],
    moderator: [
        'in need of moderator intervention', // English
        'モデレーターによる対応が必要です', // Japanese
        'precisa de atenção dos moderadores', // Portuguese
        'требуется вмешательство модератора', // Russian
        'se necesita la intervención de un moderador', // Spanish
    ],
    close: [
        'should be closed...', // English
        'クローズする必要があります', // Japanese
        'deveria ser fechada...', // Portuguese
        'должен быть закрыт...', // Russian
        'debería ser cerrada...', // Spanish
    ],
    duplicate: [
        'a duplicate...', // English
        '重複しています', // Japanese
        'repetida...', // Portuguese
        'дубликат...', // Russian
        'un duplicado...', // Spanish
    ],
};

Both the close and duplicate flag_option types contain sub_options, which vary from site to site.

These are valid as of the time/date this answer was posted, but there's nothing that requires the SE API to not change these titles. Given that the comment flags have recently been changed, more than once, it's not that unlikely that these will be changed also.

Improve this answer
1
  • Upvoted, but this could use an auto-update feature, and hosting somewhere (EG: GitHub) in machine readable (JSON, XML, etc.) form. Otherwise this answer will be useless in X weeks...
    – Brock Adams
    Commented Aug 9, 2018 at 0:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .