Code

Opened 3 years ago

Closed 18 months ago

Last modified 18 months ago

#15714 closed Bug (fixed)

Inconsistent capitalization of name_local in django.conf.locale.LANG_INFO

Reported by: claudep Owned by: nobody
Component: Internationalization Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I think that name_local in LANG_INFO should be either globally capitalized or not (in languages where that makes sense).

Currently, there is "Français" and "español", by instance.

Attachments (0)

Change History (9)

comment:1 Changed 3 years ago by lukeplant

  • Type set to Bug

comment:2 Changed 3 years ago by lukeplant

  • Severity set to Normal

comment:3 Changed 3 years ago by julien

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

I'm not sure how inconsistent Django's i18n data currently is, but globally capitalising everything would not necessarily be a welcome change. For example, demonyms are capitalised in English but not in French (see at the bottom of the "Adjectives" section in http://en.wikipedia.org/wiki/Capitalization

So, "Français" should in fact be "français".

comment:4 follow-up: Changed 2 years ago by ramiro

  • Easy pickings unset
  • UI/UX unset

Claude: What are the use cases/reasons why you think "name_local in LANG_INFO should be either globally capitalized or not".

What Julien says is correct, e.g. in spanish language names aren't capitalized ("español", "inglés", "francés").

Maybe it doesn't look nice in a select form control, or it affects sorting of the options in such an UI element? Can we provide some helper or suggestion in the docs for users that wish to solve these hypothetical problems?

comment:5 in reply to: ↑ 4 Changed 2 years ago by claudep

Replying to ramiro:

Claude: What are the use cases/reasons why you think "name_local in LANG_INFO should be either globally capitalized or not".

Consistency, mainly. When you present a list/menu with native names, it's not very nice to see : 'Basque, 'eesti', 'English', 'español', ...

What Julien says is correct, e.g. in spanish language names aren't capitalized ("español", "inglés", "francés").

Same for French. But if the language name is alone in a menu, it may be capitalized.

Maybe it doesn't look nice in a select form control, or it affects sorting of the options in such an UI element? Can we provide some helper or suggestion in the docs for users that wish to solve these hypothetical problems?

Is there currently a rule for name_local capitalization? I think it should be clarified at least in the file itself.
For example, "Capitalize name_local only if your language name should always appear capitalized in your language, even in the middle of a sentence" (if that is the rule of course).

comment:6 Changed 18 months ago by waldeinburg

If you make consistency, the filter language_name_local will be useless when the use case is, e.g., putting the current language inside a sentence on a multilingual site; it would create spelling errors in, e.g., Spanish as you mention. It makes little sense, IMHO, to use the local name outside the language itself, except in lists where you can use the capfirst filter to capitalize.

comment:7 Changed 18 months ago by claudep

Granted.

What about this note in the file:

# About name_local: capitalize it as if your language name was appearing
# inside a sentence

comment:8 Changed 18 months ago by Claude Paroz <claude@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 5dc4437dfad8241a5830e4d2ab59635b814281d6:

Fixed #15714 -- Added note about capitalization of LANG_INFO name_local

comment:9 Changed 18 months ago by Claude Paroz <claude@…>

In 5229ac20bedea017bfd29e6cb03916715c09cc7f:

[1.5.x] Fixed #15714 -- Added note about capitalization of LANG_INFO name_local

Backport of 5dc4437df from master.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.