Suggestion: Use yml instead of txt files for metadata

[NicosKaralis]

I'm new to fastlane and some things are not well explained in my head. One that still gives me a lot of headache is the metadata being a lot of txt files.

Could we use YAML to improve readability?

Structure today:

metadata
    en-US
        description.txt
        keywords.txt
        privacy_url.txt
        software_url.txt
        support_url.txt
        title.txt
    pt-BR
        description.txt
        keywords.txt
        privacy_url.txt
        software_url.txt
        support_url.txt
        title.txt

Structure with YAML:

metadata
    en-US.yml
    pt-BR.yml

YAML file contents:

title: My awesome app
description: App Description contained here
keywords:
    - all
    - the
    - keywords
    - in
    - new
    - lines
software_url: http://example.com
privacy_url: http://example.com/privacy
support_url: http://example.com/support

Is this feature wanted by the community? or just me?

Should I make a pull request for this?

[NicosKaralis]

Taking a quick look on https://github.com/fastlane/deliver/blob/master/lib/deliver/upload_metadata.rb I find very disturbing the ammount of File.read being called. There is a lot of disk reading, even for a single language.

I'm thinking on one metadata.yml with everything inside. All localized and non-localized keys. This way only one File.read would be fired and all information would be in memory.

This could make even possible a default value for each key

default: &default
    title: My awesome app - Default name
    description: App Description contained here - Default description
    keywords:
        - all
        - the
        - keywords
        - in
        - new
        - lines
    software_url: http://example.com
    privacy_url: http://example.com/privacy
    support_url: http://example.com/support

en-US:
    title: My awesome app
    description: App Description contained here
    keywords:
        - all
        - the
        - keywords
        - in
        - new
        - lines
    software_url: http://example.com
    privacy_url: http://example.com/privacy
    support_url: http://example.com/support

de-DE:
    <<: *default
pt-BR:
    <<: *default

[superarts]

Maybe one of the purposes of using txt files instead of json/xml/yml... is to avoid all the escaping etc? And I reckon it's easier to deal with languages as Arabic as well. And I kind of like txt since it's more non-tech people friendly.

[NicosKaralis]

txt or json/xml/yaml are the same in terms of usability, the difference is the way they are organized.

To clarify things, a yaml file is a txt file with a specific format. If you can write arabic characters on a txt you can also write them in a yaml

In terms of organization, it's much more effective to have one metadata.yml for all languages or one for each language than having one txt file for each key for each language.

Also. Your argument that txt is more friendly to "non-tech people" is not that valid. We are talking about a tool to help development and deployment of an mobile app. How much "non-tech people" are involved in this process?

In my projects all people involved are "tech people", from the designers to translators to marketeers, they all have tech skills to at least write a json/xml/yaml formatted file.

If I told you "this is the file and here you replace your text", can you do it? Isn't this how we send pdf's with fields? Word documents to be filled? What is different in this case?

I did not understand your escaping problem. Can you elaborate more?

[KrauseFx]

The initial release of deliver used a metadata.json file, but people didn't like it. Most of the times marketing people are responsible for the metadata and it's easier for them to just provide txt files. Additionally it's easier to send those files to 3rd party translation service.

I don't see any real disadvantage of using multiple txt files for this.

[KrauseFx]

There is a lot of disk reading, even for a single language.

At that scale, that's irrelevant

Having a json or yml file is actually more complex than it first seems, you have localised and non-localised values and version specific and generate values. That's 4 different combinations.

[NicosKaralis]

@KrauseFx I don't see how it is irrelevant. Consider your own example of multiple versions

2 versions
8 languages
3 non-localized keys per language
7 localized keys per language

2 * ( 3 + 8 * 7  ) = 118

This is an absurd amount of files to keep one app updated. And 8 languages are not a big number.

Now the same structure as yml can be one file to accommodate all keys, or one file per version

metadata-0.9.0.yml
metadata-1.0.0.yml

And the contents can be the non-localized + localized keys, like so:

copyright: text
primary_category: text
secondary_category: text
en-US:
    title: My awesome app
    description: App Description contained here
    keywords:
        - all
        - the
        - keywords
        - in
        - new
        - lines
    software_url: http://example.com
    privacy_url: http://example.com/privacy
    support_url: http://example.com/support

[NicosKaralis]

Also, @KrauseFx , the only change in the code would be to read a yml and fetch the keys from an object, much easier than reading each file.

If I kept the txt reading as it is and add support for yml as optional, could that be merged?

EDIT

Forgot to mention, I couldn't find anywhere in deliver documentation where you can put metadata relative to a version.

You can scratch that idea of metadata-(version).yml but the problem still exists

[jcampbell05]

Perhaps we allow people to chose :) I don't see the harm.

from experience marketers much prefer handing me over a word or excel document which I copy and paste in.

so a choice would really help me. But also if I could write a way of parsing it that deliver could pick up from the directory , I couldn't see why I couldn't create my own way of doing it I.e spreadsheets

[jcampbell05]

Xctool or xcpretty has a good system for this with for matters and Python scripts

[lacostej]

The current layout of having multiple files fits very well with the way we create those files (exported from crowdin.net in our case, where we crowd source translations). So marketers do not give me manual work.

If we move to a single file for input, we will have to write scripts to merge them all. Not a big deal, but not that necessary either.

If you want to change that, try not breaking existing workflows :) Support both or add scripts to move from YML to directories and vice versa

[fastlane-bot]

This issue was migrated to https://github.com/fastlane/fastlane/issues/1542. Please post all further comments there.

fastlane is now a mono repo, you can read more about the change in our blog post. All tools are now available in the fastlane main repo :rocket: