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. 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. 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 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. 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. 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: [
        'deleted as spam', // English (as of 2025-06-27)
        'spam', // Portuguese (English prior to 2025-06-27)
        'スパム', // Japanese
        'contenido no deseado', // Spanish
        'спам', // Russian
    ],
    rude: [
        //'rude or abusive', // English prior to 2025-06-27
        'deleted as rude or abusive', // English as of 2025-06-27
        '失礼又は暴言', // Japanese
        'rude ou abusivo', // Portuguese
        'невежливый или оскорбительный', // Russian
        'irrespetuoso o abusivo', // Spanish
    ],
    naa: [
        //'not an answer', // English prior to 2025-06-27
        'deleted for not answering the question', // English as of 2025-06-27
        '回答になっていません', // Japanese
        'não é uma resposta', // Portuguese
        'не является ответом', // Russian
        'no es una respuesta', // Spanish
    ],
    vlq: [
        //'very low quality', // English prior to 2025-06-27
        'deleted as very low quality', // English as of 2025-06-27
        '品質が低すぎる', // Japanese
        'qualidade muito baixa', // Portuguese
        'необходимо удалить из-за проблем с качеством', // Russian
        'muy baja calidad', // Spanish
    ],
    moderator: [
        //'in need of moderator intervention', // English prior to 2025-06-27
        'looked at by a moderator', // English as of 2025-06-27
        'モデレーターによる対応が必要です', // Japanese
        'precisa de atenção dos moderadores', // Portuguese
        'требуется вмешательство модератора', // Russian
        'se necesita la intervención de un moderador', // Spanish
    ],
    close: [
        //'should be closed...', // English sometime prior to 2025-06-27
        'closed', // English at least by 2025-06-27, but probably years earlier
        'クローズする必要があります', // Japanese
        'deveria ser fechada...', // Portuguese
        'должен быть закрыт...', // Russian
        'debería ser cerrada...', // Spanish
    ],
    duplicate: [
        //'a duplicate...', // English sometime prior to 2025-06-27
        'closed as a duplicate question', // English at least by 2025-06-27, but possibly years earlier
        '重複しています', // 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... Commented Aug 9, 2018 at 0:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.