Interface localization (2nd try)

[stefangs]

After my post from 2008:

I gave up on localization, because the buttons on the dialog boxes couldn't be filled with custom text. Now that this is possible, I'm dabbling at this again and I have a question.

For the dialog boxes, I've created a table with one record per dialog box. There's a field for the content and one each for up to three buttons. When clicking a button, I'm capturing two script parameters, one for the currently selected language and one for the ID of the proper dialog. This creates a key field and pulls out the proper text strings. This seems to work well so far (although I'm still at an early stage here).

Now with field labels that strategy falls apart, because I can't create relationships like above. There are obviously many field labels and the only thing I can think of is to create a table with a ton of global fields that contain the text strings. That seems clunky and I wonder if there's a more elegant way. it would be ideal (and easier to manage) with something like I did with the dialog boxes, i.e. a table with one text string per record in every supported language. I can't think if a way to make that happen though. Any ideas?

Thanks,

Stefan

[Agnes Riley]

Hi Stefan,

Have you thought about using the ButtonBar buttons for this and just hide the ones you don't need for the current language?

[Lee Smith]

Hi Stefangs, 

Are you still using FileMaker Pro v10?

[stefangs]

2 hours ago, Lee Smith said:

Hi Stefangs, 

Are you still using FileMaker Pro v10?

Well actually I am, but I'm developing this on FMA 13. 

3 hours ago, Agnes Riley said:

Hi Stefan,

Have you thought about using the ButtonBar buttons for this and just hide the ones you don't need for the current language?

No, haven't thought about this. Actually, I haven't even used the button bar. Perhaps a good reason to try it. 

Thanks

Stefan

[Agnes Riley]

The good thing about the button bar for you is that it allows you to calculate it's name.

[Lee Smith]

5 hours ago, stefangs said:

Actually, I haven't even used the button bar. Perhaps a good reason to try it. 

 

Button Bars were introduce in V14.

[comment]

I believe the best strategy for field labels (and perhaps for all language-dependent strings) would be to load some global variables with strings in the selected language, at the time the language is selected. How to store these strings depends on whether the number of languages is constant or not.

Note that in v.14 and higher you have the option of placeholder text, which can be calculated.

Edited March 16, 2017 by comment

[stefangs]

6 hours ago, comment said:

I believe the best strategy for field labels (and perhaps for all language-dependent strings) would be to load some global variables with strings in the selected language, at the time the language is selected. How to store these strings depends on whether the number of languages is constant or not.

Note that in v.14 and higher you have the option of placeholder text, which can be calculated.

Ok, stuffing global fields with an initial script is something I understand ;-)

That v.14 looks more tempting all the time. It's probably not available any longer, but I'll check the FM site.

Thanks,

Stefan

[Agnes Riley]

You can only get FM14 through some box options at this point form some 3rd party. You're betting off getting a good deal on 15. Ask FMI what's today's deal.

[comment]

11 minutes ago, stefangs said:

stuffing global fields with an initial script is something I understand

I said variables, not fields.

[stefangs]

I knew you would come up with something more complicated than global fields

But seriously, why would variables be better? You'd still need to store the strings in fields, right?

[Lee Smith]

55 minutes ago, stefangs said:

That v.14 looks more tempting all the time. It's probably not available any longer, but I'll check the FM site.

http://help.filemaker.com/app/answers/detail/a_id/14544/~/filemaker-15-upgrade-qualifications

[comment]

47 minutes ago, stefangs said:

You'd still need to store the strings in fields, right?

Storing them is one thing, loading them another. As I said, there are several possibilities regarding where to store the strings. Global fields are not one of them.

As for loading, let's have for example 3 tables with 20 fields each; that requires 60 "string-holders". If you want to use global fields, you will need to define 60 global fields first. With global variables, you can have the populating script create and populate them at the same time (actually, create them by populating them).

You will still have some duplication of effort, because you also need to place every "string-holder" on a layout (or several layouts).

BTW, if you want to keep it very simple, you could store the strings within the populating script itself.

 

 

[stefangs]

22 hours ago, Lee Smith said:

http://help.filemaker.com/app/answers/detail/a_id/14544/~/filemaker-15-upgrade-qualifications

Thanks Lee,

 

I'm not quite ready for a subscription based product yet. But I know we all have to succumb to the pressure eventually. Too bad I missed the v.14 upgrade cycle.

22 hours ago, comment said:

Storing them is one thing, loading them another. As I said, there are several possibilities regarding where to store the strings. Global fields are not one of them.

As for loading, let's have for example 3 tables with 20 fields each; that requires 60 "string-holders". If you want to use global fields, you will need to define 60 global fields first. With global variables, you can have the populating script create and populate them at the same time (actually, create them by populating them).

You will still have some duplication of effort, because you also need to place every "string-holder" on a layout (or several layouts).

BTW, if you want to keep it very simple, you could store the strings within the populating script itself.

 

 

Are you saying that the layouts do not have field labels until you do a scripted navigation and at that point they become populated? And how do I put a variable on a layout?? I know you can't, but what is the string-holder then?

[comment]

13 minutes ago, stefangs said:

Are you saying that the layouts do not have field labels until you do a scripted navigation and at that point they become populated?

I am not sure what exactly your question is here. If you're asking whether I suggested that field labels will be visible only after the variables have been populated, the answer is yes. Technically, you could have default labels in a default language and hide these when the variables are populated. But that would be an awful lot of extra work.

 

13 minutes ago, stefangs said:

And how do I put a variable on a layout??

Like this? http://www.filemaker.com/help/13/fmp/en/html/create_layout.9.34.html#1064499

 

 

Edited March 17, 2017 by comment

[stefangs]

Oh, now we have merge variables too!

As cool as the feature is, it is a bit of a bummer that you have to refresh every time you view a record. Before I dive into this, it would be good to know if that isn't going to be a bad user experience (screen flickering for no apparent reason, or slowing down browsing). Have you seen something like this in action?

Thanks for the link,

Stefan

 

PS, you second guessed me correct on the first part.

Edited March 17, 2017 by stefangs

[comment]

17 minutes ago, stefangs said:

Oh, now we have merge variables too!

Since v.11, IIRC.

 

17 minutes ago, stefangs said:

it is a bit of a bummer that you have to refresh every time you view a record.

Why would that be necessary?

 

You do need to consider the burden of rendering so many variables on every screen redraw. I am not sure what your requirements are, but certainly having a dedicated set of layouts for each language would be more efficient. But then you will need to replicate every design change as many times.

 

Edited March 17, 2017 by comment

[stefangs]

From the link you posted:

Important  To ensure that merge values are displayed accurately, each record must be refreshed as it is being browsed, previewed, or printed. You can refresh records manually by, for example, creating a “Refresh” button that calls the Refresh Window script step, or automatically by creating a script that includes the Refresh Window script step.

-

I think a dedicated layout for even more than one language is not practical, because there are so many layouts as it is.

Do you advise against the global field approach because global fields have a bad reputation in general when it comes to storing data?

Thanks,

Stefan

[comment]

11 minutes ago, stefangs said:

each record must be refreshed

I don't think it applies in your case, because the variables do not change when you move to another record. Try it and see for yourself.

 

13 minutes ago, stefangs said:

Do you advise against the global field approach because global fields have a bad reputation in general when it comes to storing data?

I advise against using global fields for displaying the current values, because you will need to predefine a global field (or at least a repetition of a global field) for every label. I advise against using global fields for storing data in general, because that's not what they are for.

Another thing you need to consider is that when you clone a file, all field data is lost. But your language strings are not data as such; they are part of the schema, and should be preserved when you clone a file. So think carefully where you want to store them.

 

[Wim Decorte]

2 hours ago, stefangs said:

I'm not quite ready for a subscription based product yet.

You can still buy a license of FM without a subscription... But if you make a living out of it or your business gets good value from it then going with a maintenance renewal makes a lot of sense.

[stefangs]

Yes, I missed that at first. Thanks for pointing it out.

[stefangs]

Ok, so I put together a template that shows one strategy of going about my localization project. I have included the dialog boxes also, just to show you that part, too.

I have used global variables to store the strings which would require an intial script to populate them. This isn't included in the template.

Hope that some of you can take a minute to check this out. It works, but I don't know how clunky it will get once I add probably about 100 dialogs and perhaps 200 field labels.

@comment: I'd be curious to hear your comments, mostly because I don't quite see the advantage of the variables vs. global fields.

Thanks,

Stefan

Language_demo.zip

[Fitch]

One cool thing about using variables is you can instantiate a huge list of them using a few lines of code.* That will be easier to maintain in the long run IMHO.

* e.g.: Evaluate( "Let($$" & name & " = " & translatedName & " ; 1 )" )

 

[stefangs]

I'll come back to this line in 2018

It is seriously above my level, but I'm happy to have something to chew on!

Thanks,

Stefan

[stefangs]

Just a push really...  anyone want to try my template and comment on it? Ideas for improving it? Would be happy to get some feedback!

Thanks,

Stefan