Search Unity

Question How to avoid locales being added automatically to projects

Discussion in 'Localization Tools' started by Trisibo, Jul 17, 2023.

  1. Trisibo

    Trisibo

    Joined:
    Nov 1, 2010
    Posts:
    245
    We have a Unity project with base functionality (code, scenes, prefabs, localization tables, ...) that we use to create "derived" projects for clients, with custom content. The base project is in a package that we reference in the custom projects.

    Since many of the texts and some localized assets are the same for all projects (mostly common UI stuff), and they are used by assets in the base project, we have those localization tables in it. Those tables use the locales that are used by all the derived projects, but not all derived projects use all the locales.

    We want to avoid having the locales that aren't used by each derived project to be in the "Available Locales" of the localization settings for that project, but since they are in the base project package, the localization package adds them to the localization settings of each project automatically; even if we remove them manually, they are added again when some assets are (re)imported.

    Now we have tried removing them from the base project package (placing them elsewhere in the "Assets" folder of that project) and creating them on each derived project, but now the localization package detects that some table collections of the base project use locales that aren't in the derived projects, and creates the locale assets ("The following missing Locales have been added to the project because they are used by the Collection xxx"), and, even worse, they are created in the project's "Library/PackageCache/xxx" folder, which makes Unity complain constantly that those locale assets have no meta file, but it cannot create them because it's an immutable folder. So this workaround is no good.

    Is there any way to prevent the localization package from generating the missing locales, or from adding them to the localization settings?
     
  2. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    8,282
    Hmm. One thing you could try is to create an addressables group and set it to not include, then add the locales to this. This should stop the system from trying to add them.
     
    timbokoppers likes this.
  3. Trisibo

    Trisibo

    Joined:
    Nov 1, 2010
    Posts:
    245
    A bit late, but I tried adding the locales to an addressables group with the "Include in Build" option disabled, and the behaviour is the same, when the tables are reimported the locales are moved to the "Localization-Locales" group, and are also added to the localization settings.
     
  4. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    8,282
    You will need to configure an Addressables group rules asset so that they are not moved from unknown groups. https://docs.unity3d.com/Packages/c...ual/Addressables.html#addressable-group-rules
     
  5. Trisibo

    Trisibo

    Joined:
    Nov 1, 2010
    Posts:
    245
    Weird, I can't see the "Move Entries in Unknown Groups" options in the image, only the "Read Only" ones, it's version 1.4.5.

    I'm thinking about another potential solution, which would be to create a separate package for each locale, containing only the base project's tables for that locale. The main package of the base project would still have the table collections, and their tables list just have the tables that exist in the separate packages assigned, I guess the tables don't need to be in the same directory as the table collection, right?

    Then in the derived projects we would just add the packages for the locales that the project uses, and Localization wouldn't know about the other locales and thus wouldn't create them. Also, it wouldn't create addressable groups for the tables and localized assets for those locales.

    At first sight do you think there could be any issue? The only thing I can think of is that, for the derived projects, the table collections of the base project would appear to have some tables assigned that don't really exist (for the locales not in the project), but I'm assuming that wouldn't be an issue.
     
  6. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    8,282
    Thats strange. I think we must have removed the option but not updated the screenshot.

    Its worth a try.
    Moving the tables should be ok as long as you keep the meta files with them. They are referenced by the table collection so it may create an error, have to check and see what happens. It may just handle the null values.
    Other than that I think it could work. Let me know how it goes.
     
  7. Trisibo

    Trisibo

    Joined:
    Nov 1, 2010
    Posts:
    245
    The separate packages solution seems to work so far, but I've only tested it in the editor, we need to make an actual build and see what happens. The only issue I see is that Localization indeed complains in the derived projects that the table collections reference non-existing tables every time the base project package is imported, and removes those references (in the package data in Library), which is a bit annoying but doesn't seem to cause issues so far, pending proper testing.

    I have tried another potential solution, creating a custom locales provider class and setting it in the localization settings. The custom provider does nothing in its "AddLocale" and "RemoveLocale" methods, so the locales can only be added/removed from the settings UI manually.

    So the 2 potential solutions for now, with pros and cons pending further tests, are:
    1. Separate packages per locale:
      • :) The locales can be created and set up in each project
      • :) No extra locales or locale groups are automatically added to addressables
      • :confused: Each time the base project is imported, Localization will complain that some language tables referenced in table collections don't exist, and will remove them (in the Library package data)
    2. Custom locales provider:
      • :confused: All the locales must exist in the base project package (so Localization doesn't add them automatically), the derived projects can't customize anything in them
      • :confused: Unused locales and groups are added to addressables (the groups can be marked to not include in builds, and the locales may not be a problem)
      • :) No complaints or edits to the package in Library by Localization when importing the base project
     
    karl_jones likes this.
  8. Trisibo

    Trisibo

    Joined:
    Nov 1, 2010
    Posts:
    245
    I forgot to comment on the build test results: we've only tried builds with option 1 (separate packages per locale), and it works without issues. We didn't try a build with option 2.
     
    karl_jones likes this.