What is the best practice for sources structure or config options in hybrid iOS/Android project

I use crowdin to localize both iOS and Android app. At the same time, I integrated my project branches with CLI app (3.2.0), and resulting directory structure in crowdin looks like the following:

master
  |- values // Android resources
  |   |- Android
  |   |- some_strings.xml
  |- InfoPlist.strings // iOS
  |- Localizable.strings // iOS
  |- Localizable.stringsdict // iOS

The problem is the annoying warning which is impossible to hide when downloading translations for the iOS app “Due to missing respective sources, the following translations will be omitted”:

crowdin download -l es-ES -b `git branch --show-current`
✔️  Fetching project info
✔️  Building ZIP archive with the latest translations for 'es-ES'
✔️  Building translation (100%)
✔️  Downloading translation
✔️  Extracted: 'Resources/Localization/es.lproj/AppStore.strings'
✔️  Extracted: 'Resources/Localization/es.lproj/Localizable.strings'
✔️  Extracted: 'Resources/Localization/es.lproj/Localizable.stringsdict'
✔️  Extracted: 'Resources/es.lproj/InfoPlist.strings'
⚠️  Due to missing respective sources, the following translations will be omitted:
	- values/strings.xml
	- values/some_strings.xml

How to hide it or may there is a more convenient way to separate resources in a multiplatform project. My configuration file:

"base_path": "."
"files": [
    {
        "source": "/Resources/Localization/en.lproj/*.strings",
        "translation": "/Resources/Localization/%osx_locale%.lproj/%original_file_name%",
    },
    {
        "source": "/Resources/Localization/en.lproj/*.stringsdict",
        "translation": "/Resources/Localization/%osx_locale%.lproj/%original_file_name%",
    },
    {
        "source": "/Resources/en.lproj/*.strings",
        "translation": "/Resources/%osx_locale%.lproj/%original_file_name%",
    }
]

[pavelosipov]

Hi, @og-fox Thanks a lot for your quick response! Making branches with different prefixes for iOS and Android is a good enough solution for me. I thought about it but decided to prove that workaround before implementation.

[og-fox]

@pavelosipov,

I’m sorry we didn’t notice previous question! But I’m glad to hear that you found all the answers already 😃

If there is anything else we might be able to assist you with, feel free to ping us!