Support multiple locales on the one app about vault HOT 10 CLOSED

By default Vault picks up the default locale of the space. When performing sync you can pass Vault a custom locale:

Vault.with(context, YourSpace.class).requestSync(SyncConfig.builder()
    .setClient(client)
    .setLocale("CODE")
    .build());

This however results in re-syncing the entire space, invalidating any existing data.

I think it's a good idea to persist all the locales though, as that allows switching locales while in offline mode. We can look into doing that soon.

Can you elaborate on your last point? (re the previous language not being completely removed) - one thing that might throw you off is this: contentful/contentful.java#85

from vault.

Thanks @tomxor , appreciate the fast replies. If it can be supported it would be fantastic. Will it take very long to make this enhancement to the vault library?

At the moment, my only solution is to use the contentful.java SDK to persist the different languages, it would be a shame to do that because you have written such an excellent library with the built in ORM

To answer the last point, I did a test where I downloaded content for English first. I then changed the locale in a later build and checked the data. I shall look into it a bit further and create a new ticket if i can write a test for it.

from vault.

We can definitely look into implementing this feature soon. The way to do that would probably be (as you suggested) having multiple SQLite files for the same space, and providing a way to specify the locale when making queries:

vault.fetch(Foo.class).all("en-US");
vault.fetch(Foo.class).first("en-US");

vault.fetch(Foo.class).all(); // should use the default locale

Unfortunately I'm traveling this week and will only be able to attend to this next week, however we'll do our best to push this out quickly.

from vault.

Thanks again. Look forward to the results. Also, thanks for the Rx support for the orm as well. Its working very well

from vault.

Thanks for the feedback! :)

from vault.

Having another look at this it seems that multiple SQLite files might not be the best solution, since we will end up caching (potentially) lots of SQLiteOpenHelper instances + connections, which means a much bigger memory footprint. We might be able to avoid this by just using multiple tables within one database file.

from vault.

I would agree with that perspective. I suppose the database tables would be prefixed with the locale name as well?

from vault.

Yap, I already have this implemented on a local branch, should probably manage to submit a PR tomorrow and

For every model the table name format is:

entry_{content_type_id_hash}${locale}

same applies for assets:

assets${locale}

and links:

links${locale}

This will be backwards-incompatible since the locales (at least one) must be explicitly defined with the @Space annotation:

@Space(value = "cfexampleapi", models = { ... }, locales = { "en-US", "tlh" })
class DemoSpace {
}

from vault.

Great enhancement. thanks again.

from vault.

@davetao Once again, your feedback is greatly appreciated. 🙇

from vault.