Jump to content
stefangs

Interface localization (2nd try)

Recommended Posts

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Hi Stefangs, 

Are you still using FileMaker Pro v10?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)

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 by comment
  • Like 1

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
11 minutes ago, stefangs said:

stuffing global fields with an initial script is something I understand

I said variables, not fields.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

 

 

Share this post


Link to post
Share on other sites
22 hours ago, Lee Smith said:

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?

Share this post


Link to post
Share on other sites
Posted (edited)
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 by comment
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by stefangs

Share this post


Link to post
Share on other sites
Posted (edited)
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 by comment

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 )" )

 

Share this post


Link to post
Share on other sites

I'll come back to this line in 2018 :D

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

Thanks,

Stefan

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×

Important Information

By using this site, you agree to our Terms of Use.