Can Semitic and Roman Alphabets Be Used In The Same Field

[Kent Searight]

I'm trying to setup users of RTL (Right-To-Left) alphabets such as Hebrew and Arabic to use a database the same way as current users. Current users are worldwide, using Roman, Russian, Turkish, Chinese, Japanese, Korean alphabets, and more. All those alphabets are LTR (Left-To-Right) reading and they all display and perform properly using the Arial Unicode font.

In our preliminary testing which involved importing of Hebrew translations, this was our feedback:

1. The translation file is correctly set-up and translated – Israeli team confirmed.
2. However when imported into the database it’s incorrectly shown (mix hebrew and english words)
3. It gets even worse when we create pdf file as than the hebrew is really mixed up and even the words are scrambled (right to left).
4. In hebrew words are shown like this: example in english for you, SCRAMBLED is show as DELBMARCS

The PDF file referenced in line 3 is generated by InDesign. We export data from FileMaker then call InDesign to create a PDF from the data. It's important that the data exports for InDesign are correct since the primary purpose of the solution is to create localized product brochures.

In summary, we need to do the following:

1. Support RTL alphabet display in a solution that currently supports LTR alphabets
2. Support data import of RTL alphabet without LTR characters replacing RTL characters
3. Support editing of RTL data in the solution
4. Support export of RTL data so that characters are kept in their proper order.

Does anyone have any experience with this? In my research I found that WinSoft partners with FMI to create localized versions of FileMaker products. It sounds like we could use a localized version to get around this but we'd have to create all new fields and layouts just for RTL alphabet (i.e. a fair amount of work to setup, and then maintain)

Thanks!

-Kent

[comment]

1 hour ago, Kent Searight said:

I found that WinSoft partners with FMI to create localized versions of FileMaker products.

Yes, you will need the ME version from Winsoft in order to handle RTL and LTR text in the same field correctly.

 

1 hour ago, Kent Searight said:

but we'd have to create all new fields and layouts just for RTL alphabet

I am not entirely sure that would be necessary. But you didn't tell us enough about how this is intended to be used.

 

1 hour ago, Kent Searight said:

We export data from FileMaker then call InDesign to create a PDF from the data. It's important that the data exports for InDesign are correct since the primary purpose of the solution is to create localized product brochures.

I don't know how well that would work, if at all. I don't think Filemaker exports the paragraph direction settings (except when you export as a Filemaker file).

[Kent Searight]

I think this gives me enough info to know where to focus my research.

Your last comment about data export puzzles me a little though. If FM doesn't preserve the RTL character flow, then how do RTL text users deal with tab or comma separated data if it gets reversed on export? Or am I misunderstanding your statement?

Thanks for the help, Michael.

-Kent

[comment]

51 minutes ago, Kent Searight said:

If FM doesn't preserve the RTL character flow, then how do RTL text users deal with tab or comma separated data if it gets reversed on export? Or am I misunderstanding your statement?

I believe you may be misunderstanding how this is supposed to work. Data as such is never reversed. In Unicode, characters are always entered and stored in logical order. It is the job of the rendering application to display the character data in the expected visual order - which may be different from the order the characters were entered.

In the ME version of Filemaker, you have the option to define paragraph direction. This works very much like text styling, in the sense that you can define a default for the field in Layout mode, and override it in Browse mode on a paragraph-to-paragraph basis.

A LTR paragraph displays the characters from left to right, until it encounters a block of RTL characters, which are then displayed in "reverse" order (relative to the paragraph direction). This is the preferred mode for predominantly English text, with some Hebrew mixed in. For the opposite situation, where you have some English phrases mixed in a predominantly Hebrew paragraph, you would set the paragraph direction to RTL. Such paragraph will be rendered from right to left, until a block of LTR characters is encountered.

All this happens at the layout level and has no reflection in the data itself. Again, similar to text styling, the paragraph direction settings are not exported in any of the text export formats.

[Kent Searight]

I hadn't thought about it that way, but it makes sense.

So, to take this a step further and apply it to PDF creation in InDesign, it would be up to InDesign's text box formatting (or possibly even a plugin's formatting options) to display the exported text in the desired direction flow. In other words, if the text is exported as "DELBMARCS" and I want it to display as RTL, then RTL formatting for the text box would instruct it to display as "SCRAMBLED". Does that sound about right?

[comment]

I am not sure, I am a little confused by your example. I think you will have to ask someone who knows about InDesign in general, and the handling of bi-directional text in InDesign in specific.

I suspect it works in a similar way as it does in Filemaker ME (after all, WinSoft did the ME versions for Adobe too). If so, you would not see a word displayed with its characters in inverted order - but you are liable to see words in the wrong order, if the paragraph direction is not adjusted to fit the author's intention.

 

 

Edited December 2, 2015 by comment

[Kent Searight]

Sorry, I wasn't expecting you to know InDesign. My question was more generic in nature, referring back to how you described data storage versus display.

I think I have enough info now to at least know where to look for answers and which questions to ask.

Thanks again, Michael, you've been a big help!

-Kent