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

Implementing right to left text support #310

Closed
wants to merge 37 commits into from
Closed

Conversation

sgrieve
Copy link
Contributor

@sgrieve sgrieve commented Mar 20, 2018

This is a work in progress PR to manage the work required to support right to left text, e.g. Arabic within ATF files. The complete scope of this still needs to be defined.

Initial work has identified that we can change the text direction by editing the ComponentOrientation within the constructor of AtfEditArea. however, this results in strange behaviour, where the first character of a line (in left to right mode) is moved to the far right of the line in right to left mode. This also happens when we use the keyboard shortcut documented in #297, which appears to do the same thing.

Updating master to version 0.7.1
Merging changes for version 1.0.0
@sgrieve sgrieve self-assigned this Mar 20, 2018
@sgrieve
Copy link
Contributor Author

sgrieve commented Mar 20, 2018

Upon further exploration it appears that the issue is not with the first or last character of a line, but with punctuation marks at the start or end of lines. See these examples:

screen shot 2018-03-20 at 15 20 51
screen shot 2018-03-20 at 15 21 06
screen shot 2018-03-20 at 15 23 02
screen shot 2018-03-20 at 15 23 17
screen shot 2018-03-20 at 15 23 52
screen shot 2018-03-20 at 15 24 32

I do not understand the exact set of characters that are moved around, and can't find any documentation about it. The next step is to speak with Arabic speakers and users to understand the scale of the impact this will have on maintaining correctly formatted ATF files.

@ageorgou
Copy link
Contributor

I'm seeing something similar with punctuation when changing the text direction of HTML pages. Perhaps this is an issue with what constitutes a "word" in a right-to-left language for the purposes of display?

@ageorgou
Copy link
Contributor

It seems this may be the expected behaviour. A (hopefully) useful description of why it happens and how to work around it: https://www.w3.org/International/articles/inline-bidi-markup/uba-basics

@sgrieve
Copy link
Contributor Author

sgrieve commented Mar 21, 2018

The initial plan is to preserve left to right text for the headers and transliterations and lemmatizations. Then switch to right to left for the translations in Arabic. There are language codes in the atf format to signify a change of language.

We are assuming a single atf header per file so there will be one switch from left to right to right to left per file.

Next step is to understand how to do the switch at a specified point in the file.

@sgrieve
Copy link
Contributor Author

sgrieve commented May 1, 2018

The MWE added in the last commit shows how to interleave text directions on a line by line basis.

@sgrieve
Copy link
Contributor Author

sgrieve commented May 2, 2018

Big step forward, as we have now got right to left text mixed with left to right text in the same document:

screen shot 2018-05-02 at 13 01 38

(@EleanorRobson )

There are still a lot of issues to resolve surrounding the precise styling of the arabic lines, and ensuring that the syntax highlighting does not break.

more pom edits based on the previous PR

more pom edits based on the previous PR

more pom edits based on the previous PR
@sgrieve
Copy link
Contributor Author

sgrieve commented May 3, 2018

The right to left text is mostly working now. One issue is that if the language code is changed from ar, the translation will not switch back to left justified.

EDIT: this has now been resolved

@sgrieve
Copy link
Contributor Author

sgrieve commented May 3, 2018

Based on #315 we will need to add support for:

  • ar = Arabic
  • fa = Farsi/modern Persian
  • ku = Kurdish

and for:

  • labeled translations
  • unitary translations

sgrieve added 20 commits May 4, 2018 09:46
more pom edits based on the previous PR

more pom edits based on the previous PR

more pom edits based on the previous PR
…ate an easy way of adding new languages or translation types in the future
@sgrieve
Copy link
Contributor Author

sgrieve commented Jul 5, 2018

This branch has been merged into #318 so this PR is not closed.

@sgrieve sgrieve closed this Jul 5, 2018
@ghost ghost removed the in progress label Jul 5, 2018
@raquelalegre raquelalegre deleted the right-to-left branch February 20, 2019 13:36
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

Successfully merging this pull request may close these issues.

None yet

2 participants