[bug] errors messages are hard-coded in english

[iambumblehead]

https://github.com/graphql/graphql-js/blob/main/src/validation/rules/ProvidedRequiredArgumentsRule.ts#L50-L52

new GraphQLError(
    `Field "${fieldDef.name}" argument "${argDef.name}" of type "${argTypeStr}" is required, but it was not provided.`,
     { nodes: fieldNode },
),

The error messages should, in some way, be customizable and i18n friendly. Typically, an express or koa service uses the 'Accept-Language' header to determine the message language,

const locale = ctx.get( 'accept-language' ) || 'en-US';

Using npm packages i18next, i18n or nanostores/i18n a message is ultimately rendered in the following way,

i18nMessage( locale, messageKey, { fieldDefName, argDefName, argTypeStr });

Customizing error messages is mostly impractical at the moment due to overly complicated work-arounds needed.

[saihaj]

This is a reference implementation and this feature requests seems an overkill to introduce a need of dependency. If you want to customize the errors I would recommend creating a custom validation rule and pass that to validate function

graphql-js/src/validation/validate.ts

Lines 38 to 46 in 16503cd

	export function validate(
	schema: GraphQLSchema,
	documentAST: DocumentNode,
	rules: ReadonlyArray<ValidationRule> = specifiedRules,
	options?: { maxErrors?: number },
	/** @deprecated will be removed in 17.0.0 */
	typeInfo: TypeInfo = new TypeInfo(schema),
	): ReadonlyArray<GraphQLError> {

[iambumblehead]

The original comment doesn't specify adding any dependency as a solution (and I don't believe any dependency needs to be added). In fact, one could argue graphql-js is currently doing too much.

There are numerous ways to support custom error messages, for example something (hypothetical) like this would let users of graphql-js return their own error messages, using any scripts they wanted.

hookErrorMessageCreate: ( ctx, errType, errParams ) => {
  const locale = ctx.get( 'accept-language' ) || 'en-US';
  if ( errType === scalarvalidation )
    return i18nMessage.scalar( locale, 'error_scalar_validation', errParams.fieldName );
}

[JoviDeCroock]

I don't think it's worth for a reference implementation to shift their error messages in a localized format. However, the only user facing issues are the validation rules so there could be an effort to provide a localized set of validation rules.