You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm creating a new website. One languages of this website is Serbian. But there is one feature of Serbian language - it has two scripts: cyrillic and latin and both are widely used.
I created two locales: one for latin script and one for cyrillic.
The rest of setup is done staight according to Wagtail-localize documentation.
Expected behavior
/sr-latn/somepage/ - gives latin Serbian
/sr-cyrl/somepage/ - gives cyrillic Serbian
How this works for real
/sr-latn/somepage/ - gives latin Serbian
/sr-cyrl/somepage/ - also gives latin Serbian
In admin interface I can turn on all three locales, set up syncing between locales. And in admin I see three site trees for all three locales. I can create page within every locale and get unique translations for every locale of the same page. At this point everything seems good.
But when I'm going to the website both prefix pages /sr-latn/somepage/ and /sr-cyrl/somepage/ gives me only latin variant of page.
If I will push "bird button" -> Edit this page on /sr-latn/somepage/ and on /sr-cyrl/somepage/ both link leads me to the same latin page in admin, even if both variants of page(latin and cyrillic) are exists.
For example:
/admin/pages/19/edit/ - latin Serbian
/admin/pages/21/edit/ - cyrillic Serbian
But /sr-latn/somepage/ and /sr-cyrl/somepage/ refers only /admin/pages/19/edit/
I don't know is this the issue of wagtail-localize or wagtail, or may be django itself, but I'll be very appreciate if someone help me make everything works.
Upd I forget to mention, there is a workaround, instead of Latin Serbian it is posible to specify Croatian locale. But it is not desired setup, because languages are not identical. For example names of the months are completely different in this languages, and thats produces another issue for blog pages...
The text was updated successfully, but these errors were encountered:
As I studied this is not so common that two scripts (and two locales as the result) corresponds to one language.
And funny thing, that Django distinguishes Latin and Cyrillic alphabet for Serbian. And It seems that i18n uses just 'default' Serbian for both Latin and Cyrillic requests.
I'm creating a new website. One languages of this website is Serbian. But there is one feature of Serbian language - it has two scripts: cyrillic and latin and both are widely used.
I created two locales: one for latin script and one for cyrillic.
I added this to settings
The rest of setup is done staight according to Wagtail-localize documentation.
Expected behavior
/sr-latn/somepage/ - gives latin Serbian
/sr-cyrl/somepage/ - gives cyrillic Serbian
How this works for real
/sr-latn/somepage/ - gives latin Serbian
/sr-cyrl/somepage/ - also gives latin Serbian
In admin interface I can turn on all three locales, set up syncing between locales. And in admin I see three site trees for all three locales. I can create page within every locale and get unique translations for every locale of the same page. At this point everything seems good.
But when I'm going to the website both prefix pages
/sr-latn/somepage/
and/sr-cyrl/somepage/
gives me only latin variant of page.If I will push "bird button" -> Edit this page on
/sr-latn/somepage/
and on/sr-cyrl/somepage/
both link leads me to the same latin page in admin, even if both variants of page(latin and cyrillic) are exists.For example:
/admin/pages/19/edit/ - latin Serbian
/admin/pages/21/edit/ - cyrillic Serbian
But
/sr-latn/somepage/
and/sr-cyrl/somepage/
refers only/admin/pages/19/edit/
I don't know is this the issue of wagtail-localize or wagtail, or may be django itself, but I'll be very appreciate if someone help me make everything works.
Upd I forget to mention, there is a workaround, instead of Latin Serbian it is posible to specify Croatian locale. But it is not desired setup, because languages are not identical. For example names of the months are completely different in this languages, and thats produces another issue for blog pages...
The text was updated successfully, but these errors were encountered: