Digital Workshop

Apparently, there is only one way to make a publication in different languages - to insert variable into text blocks and to change values depending on the choice of language. The problem of how to write these variables.

There are a few ideas of how this can be implemented:
1. Text file.
2. In the INI file.
3. The database Access
4. The database SQlight

Someone has faced such a challenge?
In what format is better to keep the variables that had easy and fast access and safe storage?

How complex is your publication? If it is simple enough, can you create duplicates in the requisite languages?

Volgar wrote:
'only one way'...is that true? Depending on what you want to do, and what (content, translations, sources,...) you have at hand at development time, the answer is different.

If content not available immediately, or it will change, external files or database has some advantage... maybe.

If you already have your content prepared in, say, 3 languages... and you wanted to embed these in Opus while you are creating the Pub, then there are a couple ways.
1. you could have duplicate Pages in separate chapters. Chap3A, Chap3B, Chap3C,... Chap4A, Chap4B and so on (many pages each chapter). You simply "fill" the copied pages with the alternative language text sections. And of course you would have your code or logic to direct the user to Pages in the alternative Chapter.

another way:
2. You could use MultiFrame feature, and have each FrameA, FrameB, FrameC for that one Page... contain specific language. On-show or pre-show actions can automatically present A, B, or C frame.

Similar to MultiFrame.... you could use standard Frames (A, B, C...) and use Opus "FrameC.SetLayer(3)" to bring just that frame to the forefront at runtime. You're achieving the effects of MF, just managing it more manually. (a small advantage is that it may be easier to work on individual Frames in Opus editor -- my experience).

As for .INI and Databases, both have their merits. INI is almost no-hassle... you just have to get used to the layout pattern and how sections are referenced. I am working on SQLite DB to populate different text objects... not diff languages, but variable selections based on User navigation. There's a definite learning-curve (for me) to understand what's possible and how to get there. Sometimes 'reversing direction' and going back to the 'drawing board'. I'm investing the time, since I want something reusable.

I think even if you use Opus' native capability for reading-in from Files (ReadLine or ReadField), it is relatively fast. What do you mean by 'safe'? There have been a few recent, and older, posts about protecting content files and about data encryption.

My publication is quite complex. A lot of graphics, scripts, 10-15 pages. If I create duplicate of pub, the size almost doubled. It is not appropriate.

Thank you

Lar_123, thank you. As usual, you have given detailed advice.

When I spoke "safe storage", I had in mind encryption.

Lar_123, could you put the code or some file with the publication of the most frequently used functions SQLite for display list of data, insert of new records, change, delete, query on the condition?

Volgar --

Several years ago I had to build a multi-language presentation. Duplicating Pages (many with large videos) wasn't pratical because of the resulting HUGE Pub size. I created an opening Page which required the viewer to select which language they wanted to see. That set a Variable I called "Language" to either a value of "1" for English, or "2" for French. It would have been easy to set several other options for more languages in the future.

Each Page had an On Show which made a Frame visible for the correct language. I only had to create one set of graphics/videos so the size was compact and maintenance was accomplished on one Page rather than two (or more). A French translator took the English text and converted it, so I could simply Copy & Paste their work into a Text Object within the French Frame. There were usually more than one Text Object on each Page and often graphics were in English or French, which is the reason I used Frames instead of simple Text Objects. Your situtation may allow for using Text Objects rather than Frames.

I highly recommend this method for creating multi-language Publications.

demofred, thanx.
Yes, and I suppose that this is the most convenient way.

A few months ago I posted a 'Getting Started w SQLite' example (Mackavi hosted the download). At that time I did not have INSERT or UPDATE function working.

That sample Pub had some 'universal' queries built-in. Which was fine for reading from the DB. But I had difficulty editing the DB via 'universal' SQL statements. The point being, the UPDATE or INSERT statements are better done specific to your dataset and current scenario.

Some hints:
-- you'll want the "Getting Started" pubs previously posted, to use the following
-- use the Firefox plugin, SQLite Manager. Under its "Execute SQL" feature it is easy to construct and test an INSERT statement... etc.
-- then Copy & Paste that SQL statement into your OpusScript... and there you modify it with Variables to pick-up the values you need.


There is a 'catch' to making the above work. SQLite likes VALUES to be in quotemarks. (except when Primary Key is Integer).
so...before the Insert or Update is sent to SQLite, we prepare Opus data to be SQL 'values'
then you may or may not need to run a Loop to ravel the Array (I use the loop to do other things here as well):


For Updating, start with something simple and test as suggested above. When you want to script it... here is somewhat of a template (again, I had certain things in mind when I constructed this... there ARE simpler ways)



In case anyone has gotten lost trying to follow this, the SQLite demonstration .imp has 3 Script Objects included which do the 'behind the scenes' work of using SQLite DB with Opus. The ScriptObject "TextSQLite_1" or similar named script is a convenient place to create "function Test2()" noted above. I would suggest separate ScriptObject to create these Opus functions:
function dbINSERT1(args)
function dbUPDATE1(args) etc.
and build-in your variables there, including SQL Queries as constructed in examples above... make your function calls to "Test2(arg)" from there. There is a lot of power here... since data read from the Database is placed in a volatile Array named "Rows"... which you can make persistent by making Records_Array1 = Rows ; //(or similar named Array variable)
That's what you are operating on in Opus.

added Hint:
-- when you execute a DB UPDATE or INSERT statement from an Opus Pub, you can immediately go over to SQLite Manager ( Alt+TAB to Firefox/sqlite_manager) and HIT the REFRESH button.... you will see your changes to the Database in the "Browse & Search" Tab in SQLite Manager.

Good cheer.
Lar

Lar_123, many thanks. Already study.