Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handles transliteration trouble #1819

Closed
acidbeast opened this issue Sep 16, 2013 · 24 comments
Closed

handles transliteration trouble #1819

acidbeast opened this issue Sep 16, 2013 · 24 comments
Assignees

Comments

@acidbeast
Copy link

At version 2.2.5

<entry id="38">
    <nazvanie handle="otraslevye-obzory">Отраслевые обзоры</nazvanie>

after upgrade to 2.3.3 i have:

<entry id="38">
    <nazvanie handle="Отраслевые-обзоры">Отраслевые обзоры</nazvanie>

Is that ok? or something goes wrong?
I use handles as part of URL, and now that's a problem.

@nilshoerrmann
Copy link
Contributor

Do you have the correct language activated in the backend? The transliterations are provided by the language extensions.

@acidbeast
Copy link
Author

Yes, extension "lang_russian" installed and activated in settings.

screen shot 2013-09-16 at 6 25 55 pm

screen shot 2013-09-16 at 6 26 43 pm

@nilshoerrmann
Copy link
Contributor

Can you check please, if the file lang/lang.ru.php contains the needed transliterations? Thanks!

@acidbeast
Copy link
Author

Sure,

there is array $straight = array( with all required transliterations, for example

 'Ö' => 'Oe',

or

'/Г/' => 'G',

for all kind of characters (uppercase, lowercase, special, symbolic and others).

@nilshoerrmann
Copy link
Contributor

In this case, @brendo will have to take a look into it.

@brendo
Copy link
Member

brendo commented Sep 17, 2013

Interesting! What field are you using? There was a dependency on the Lang class from within General so it was abstracted to two functions, Lang::createHandle and General::createHandle. My guess is the field is just using General::createHandle.

@acidbeast
Copy link
Author

I use text input.

@nilshoerrmann
Copy link
Contributor

We are using the German language pack and never encountered anything similar with Symphony 2.3.3.
Could you give us a link to the language pack you are using? Thanks!

@nilshoerrmann
Copy link
Contributor

By the way, are you using the tagged 2.3.3 release or are you using the integration branch?

@acidbeast
Copy link
Author

Link to language pack http://symphonyextensions.com/extensions/lang_russian/ and i use only release when update symphony.

@brendo
Copy link
Member

brendo commented Sep 17, 2013

Yep, the Text Input field is at fault here. Fix on the way!

brendo added a commit that referenced this issue Sep 17, 2013
@acidbeast
Copy link
Author

Thanks guys.
I add changes to my symphony, but it still no work :((

<title handle="Тест">Тест</title>

@brendo
Copy link
Member

brendo commented Sep 17, 2013

Did you resave the entry?

@brendo
Copy link
Member

brendo commented Sep 17, 2013

Confirmed, investigating :)

@ghost ghost assigned brendo Sep 17, 2013
@acidbeast
Copy link
Author

Yes,i resave entry and resave section with handle for sure.

@brendo
Copy link
Member

brendo commented Sep 17, 2013

The bug is with the Russian Language pack, I've submitted a PR to the extension :)

@acidbeast
Copy link
Author

Yup, thanks a lot!

@nilshoerrmann
Copy link
Contributor

Out of interest, what is that General::createHandle() function for – compared to Lang::createHandle()?

@brendo
Copy link
Member

brendo commented Sep 17, 2013

Sorry? Not sure I understand what you're asking :)

@nilshoerrmann
Copy link
Contributor

Why do we have two handle creating functions?

@brendo
Copy link
Member

brendo commented Sep 18, 2013

One cares about language, the other does the basics. They aren't two
completely separate pieces of logic. It was to decouple the Lang class from
the General class.

Take a look, the Lang does it's thing and passes off to General to complete
:)
On 18 Sep 2013 14:57, "Nils Hörrmann" notifications@github.com wrote:

Why do we have two handle creating functions?


Reply to this email directly or view it on GitHubhttps://github.com//issues/1819#issuecomment-24640997
.

@nilshoerrmann
Copy link
Contributor

I cannot think of any place where a handle function without language support is sufficient, that's why I'm asking.

@designermonkey
Copy link
Member

Neither can I, I thought it did it by default, though I haven't ever translated anything.

@nilshoerrmann
Copy link
Contributor

Looking into the general function, there are quite a few things I consider natural tasks of the transliteration function:

That's what transliterations are for: mapping unsafe characters to a safe equivalent, which might either be an ASCII character or none at all.

Transliteration provided by language extensions are always merged with the core ones so it would be save to have the above replacements in there directly. If a translator decides to override the defaults, that's just fine. Otherwise translations should only include additional transliterations needed for the specific language.

There is also this option allowing for custom replacements in General::createHandle():
https://github.com/symphonycms/symphony-2/blob/master/symphony/lib/toolkit/class.general.php#L352-L354
This is just a duplicate of how transliterations work.

––

To make my point clear:

  1. General::createHandle() should make proper use of transliterations, they are always bundled with Symphony and are not specific to localised installs.
  2. Additional rules seem superfluous.
  3. General::createHandle() should be removed, Lang::createHandle() is the only proper place for this function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants