@femmdi said he will look into it. I think we decided to use Camel Case, because most strings already use that. Then there are fewer strings to change.
You mean Title Case? I wouldn’t necessarily take the number of strings to change as a guiding criterion, this is more of a design and usability choice. I would encourage to look at what other high quality apps do.
We talked about that and decided that the variant doesn’t matter too much, as long as it’s consistent. Changing only a few strings avoids the translators having to touch all the strings again because the source string changed
@ByteHamster: I started looking into this - should we apply consistent use of capitalization across all titles and labels? It’s currently a mixture of sentence case and title case and it’s more than a few strings.
@loucasal: I also checked what other companies/ projects are doing:
Google: sentence case
Microsoft: sentence case
Apple: title case for buttons and labels
KDE: title case for titles, header, menu items etc
GNOME: title case for header bars, tab titles, view titles and short control labels
There’s also a good article here that summarizes the pros and cons. Bottom line: It’s a question of choosing one or the other and - most importantly - being consistent 
2 Likes
Moved this to its own thread because it was getting a bit longer and we’re not done yet 
Not sure if that was your question @femmdi, but I would start with the all settings (global + podcast). Any other text can be looked at later.
Thanks for sharing that article also.
I had to look up what was meant by Camel Case and delighted to find something I so often use in filenames etc has such a fun name. Personally, I am a little irked by seeing User interface in Settings rather than User Interface but I can live with it.
@femmdi made a PR to apply Camel Case. I noticed there that also the Home screen was updated to use camel case, which, to be honest, I’m not a huge fan of.
I was under the impression that we were only talking (at the community meeting) about the Settings screen. But the ticket also mentions this:
Outside of the settings, I spotted the following instances:
- Playback History (screen title)
- Add Podcast (screen title and “Add Podcast by RSS address” option)
- Home: “Configure Home Screen” option
- Queue: “Clear Queue”, “Lock Queue” and “Smart Shuffle” options
- Downloads: “Download Log”
Personally, given this article:
I would use camel case only in the settings (which are harder to read because they’re long lists, which is where camel case can help). The rest of the app would then use sentence case (which, as the article notes, aligns with Google’s approach, is less formal and easier as a rule).
Just for clarity on terminology:
- Sentence case looks like this
- Title Case Looks Like This
- CamelCaseLooksLikeThis
It is also worth noting that this is an EN-only discussion, as practices vary across languages (e.g. German capitalises nouns, etc.).
My ticket assumed we would want to use sentence case consistently (without providing much in terms of a rationale, at least initially - my bad for assuming this would be entirely uncontroversial).
For that reason, I only listed (a subset of?) the instances where we were using title case outside of the settings. If the decision goes the opposite way, then my list is not that helpful.
Given that we are in an Android environment and AntennaPod follows the Material Design guidelines for its UI/UX, I don’t see why we should ignore them when it comes to text strings.
Btw, I do have at least an app installed that consistently uses title case on Android (Citymapper) and I find it very awkward. It looks to me like it was designed with iOS / a US public in mind.
Another link to complement @femmdi’s great research:
An important takeaway message from both articles is the need for consistency. (And I guess you know where my preference lies by now. 
)
1 Like
Quick update: As discussed in the last community call on May 13th, we will move to sentence case for simplicity and to follow Material Design guidelines. I’m currently working on the updates & PR.
1 Like
I would like to go back on this issue. Since you are changing strings case I, as translator, would also like that you could take care of sentences ending dot (.) There is some inconsistency in strings. In same settings part, for instance “Interface”, some strings have ending dot and others don’t. This is rather strange, IMO.
Thanks
Hi @smarquespt
Thanks for bringing it up, that’s a good point (no pun intended).
This only goes for the setting explanations; none of the titltes have a period. I would say we remove them from everywhere at the end, and only keep the ones that separate sentences within a single explanation.
So like this:
Remove the period.
Maintain the period.
@ByteHamster @femmdi Makes sense to you? If yes, I can submit a PR.
I must say having periods in the first sentence and not in the second sentence within the same string seems like a step backwards.
I would keep them for multi-sentence strings and not for single-sentence strings. That seems to be in line with the Material Design style guide on grammar and punctuation.
1 Like
I agree. I wonder how many strings could be simplified to just have one sentence instead of two. That would work around the problem
Good luck with that ^^ I’m not gonna try. (I’m too wordy, no point in trying)
Thanks @smarquespt for flagging this, and apologies for the late follow-up. I’ve just created a Pull Request to address the inconsistencies: Remove periods for single sentences by keunes · Pull Request #6707 · AntennaPod/AntennaPod · GitHub
1 Like
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.