Some Slavic languages use both Cyrillic and Latin alphabets as equal.
This creates problem for translators because they have to have 2 versions of translations, so this doubles the translation work.
The better solution of course is to translate in one alphabet and than use a script that converts from Cyrillic to Latin (or vice versa)
But than you still have 2 static translations.
What is required is for this to be done at runtime, inside the t() function, after localization, that is just before the function returns it's value (thus postprocessing)
This postprocessing issue is not applicable only to Slavic languages but to Asian and Middle-East languages as well.
Read about it here: http://www.languagetutoring.co.uk/languages-with-different-alphabets.html
The Latin alphabet is the alphabet the main languages of Europe use. It is the alphabet you are reading now and the only alphabet many English speakers will be familiar with. It is one of, if not the, most widely used alphabets in the world. The Latin alphabet is so widely used that many other languages which do not use it, such as Greek and Chinese, use a system of transliteration whereby the words of their language are replicated in a Latin alphabet so that anyone will know how to pronounce them as long as they are familiar with the Latin alphabet. These transliterations are often known as Romanizations – after the Roman Empire which led to the spread of Latin.
How it whould work:
Postprocessing has to depend on some variable (so it can be turned on/off) and it would seem(wrongly as we will see later) that best place to store that variable is as another column in the {languages} table.
Do NOT use a boolean for this column.
I recommend using integer variable, for supporting languages with more than 2 alphabets or with more alphabet sub-types.
(issues of national minorities, etnic groups, country regional language differenced etc.)
So lets assume {languages} table has a new integer column named 'alphabet'.
Here is how it should work: (pseudocode)
$alphabet = select alphabet from {languages} where language = 'xx';
if ($alphabet > 0) then
$string = hook_tpostprocess('xx', $alphabet, $string)
endif
So if alphabet is zero that means: use default = no postprocessing.
If alphabet is greater than zero pass it to a hook
Hook is to be implemented by specific language modules.
So after installing Cyrillic translation for some language from Slavic group all I have to do is change alphabet variable to 1 and
my whole site will be displayed in Latin characters.
But what if some users want to view the site in Cyrillic while others prefer Latin?
Easy: add 'alphabet' variable to the {users} table instead of {languages} table.
{languages} table could than hold a boolean variable while {users} has an integer variable.
So if {languages}.alphabet is false that means language does not have multiple alphabets
(or support for them in not installed)
$postprocess = select 'alphabet' from {languages} where language = 'xx';
if ($postprocess == TRUE) then
$alphabet = select 'alphabet' from {users} where uid = $uid;
if ($alphabet>0) then
$string = hook_tpostprocess('xx', $alphabet, $string)
endif
endif
End user perspective:
Admin installs drupal with translations for your language and than installs alphabet module for your language.
This module creates a block that is for example displayed on front page and in it users can select their preferred alphabet.
It comes down to one user click!
Comments
Comment #1
cohadar commentedI have done some research on this subject lately, it appears that solution I have suggested previously will not do.
The problem with romanization is that you usually want to do it both to interface and user content.
So it appears to be similar to multilingual site problem, but more automated.
So perhaps the best way to do it would be by overriding theme functions.
I am working on a romanization module so we will see what this turns out into.
Comment #2
marcvangendNot critical for Drupal 7.
Cohadar, if you're planning to submit a core patch for this, please set the version for this issue to 8.x-dev. New features are not added to Drupal 7 anymore.
If you're writing a contrib module, you can set the status to won't fix.
Comment #3
Zarevac commentedI am really interested in this. Is there a working alternative for D7? It would reduce my workload considerably but I dont know if a core hack or module is the best solution?