Ticket #2249 (new defect)

Opened 11 months ago

Last modified 6 months ago

locale in Translatable

Reported by: simon_w Owned by: simon_w
Priority: medium Milestone:
Component: Sapphire Framework Version: 2.2.1
Severity: medium effort / impact Keywords:
Cc: ischommer Hours:

Description

Currently, when using ?lang in the frontend, any calls to _t() are not translated.

This is a hack (only until there's a default locale for each language) that updates the locale as well as language.

Attachments

Translatable.php.diff (1.8 kB) - added by simon_w 11 months ago.
locale.diff (4.5 kB) - added by simon_w 6 months ago.
The updated patch

Change History

Changed 11 months ago by simon_w

Changed 9 months ago by sminnee

  • cc ischommer added

This duality between front-end language selection and back-end language selection needs to be resolved.

In the short term, Ingo, can you see whether we should apply this patch?

Changed 9 months ago by ischommer

we decided early on in the i18n concept that we distinguish between a narrow frontend language pool ("en", "de", ...) and a broader backend pool ("en_US", "en_UK", "de_AT", ..). the "backend" language definitions are in fact not as clearly separated as we thought, hence the problem.

as far as i see, we can leave the current system in place, but if an ambiguous "short locale" is used on a website ("en" instead of "en_US"), we need an implicit or explicit lookup from "short locale" to "long locale". i18n::$tinymce_lang does something similiar already:

	static $tinymce_lang = array(
		'ca_AD' => 'ca',
		'ca_ES' => 'ca',
		'cs_CZ' => 'cs',
		'cy_GB' => 'cy',
		'da_DK' => 'da',
		'da_GL' => 'da',
		'de_AT' => 'de',
		'de_BE' => 'de',
		'de_CH' => 'de',
		'de_DE' => 'de',
...

so "forum/?lang=de" would set "de_DE " as the reading_lang (and include /forum/lang/de_DE.php). if you want austrian german in your language setting, you have to use "forum/?lang=de_AT (need to confirm its actually possible to set "long locales" in the frontend language selection)

the patch does an implicit lookup, which seems fine to me (might be better placed in i18n::convert_to_long_locale())

Changed 6 months ago by sminnee

  • owner changed from sminnee to simon_w
  • type changed from patch to defect

"the patch does an implicit lookup, which seems fine to me (might be better placed in i18n::convert_to_long_locale()) "

I agree with that. Simon, would you be able to update the patch so that the "long locale guesser" was implemented as a separate function. Then we could change the short-to-long logic in one place, if we ever need to.

Changed 6 months ago by ischommer

hi simon - any updates on this ticket (as per sams suggestions in previous comment)?

Changed 6 months ago by simon_w

The updated patch

Changed 6 months ago by simon_w

Updated the patch.

Note: See TracTickets for help on using tickets.