Localized Strings for Months

Feature description:

Posted on behalf of @Zyntaxyz
(Last one, sorry for spam)

Additional custom string templates to display the names of the months.
For example, display 2000-01-04 as January 4, 2000 for English or Enero 4, 2000 for Spanish.

Problem solved:

YYYY-MM-DD format is efficient but not the prettiest to look at

Brought benefits:

Allows for more human-friendly date layouts. If added as localized strings, allows these layouts to be applicable to multiple locales.

Separate access to MM and DD components could allow for e.g. displaying only month (without day), or conditioning on month/day

Other application solutions:

 

 

Additional description and context:

 

 

Screenshots / Mockup:

    

2 Likes

Mockup

Similar to music streaming apps

Apple Music

Qobuz

Why do you post things on behalf of another ?

His example clearly shows that it’s not what he’s after, so if it’s the same for all it’s just time lost for no reason.

He’s grown up enough to make his own to avoid any interpretation issues.

Actually I was making right now the “master”/main feature request explaining why I asked @Celorien help to make all these requests and grouping all of them. The answer is very simple, initially I was thinking make a big feature request but, as you know, my English is far from perfect so maybe that would be a little chaotic, given proper structure to all features in only one request and well, he’s a native English speaker, I think he did a great job explaining with an understandable text, better than I could. I don’t see anything wrong with this, it’s good learn from other people, specially if they’re from the countries that you want to learn their language :slightly_smiling_face:

They are not a native English speaker so they DM’d me to help write the posts. We communicated on the ideas and I posted them in a way that is generally applicable rather than verbatim.

But I did spend time making sure that what I wrote covers their needs.

His example shows he want the about part converted, not custom strings in the header.

That’s a very different need than adding custom months with people having to handle 12 if to display a month :wink:

True. In some spots I combined their idea with something I thought would make it applicable to more people. Which complicates the request without being for their benefit.

This whole batch of posts was pitched to me as a single idea, with the goal of making strings perform as an alternative to the About section. (Edit: plus a few misc. ideas like this date formatting and the random album sort)

It was my choice to break that up into several requests so that you would have one post to track per function to add. They wanted to post it all as a single request, which I thought was not what you usually ask for.

So, should I keep making the “grouping” post? Or you already connected all the ideas from all these requests and making a grouping post would be redundant? :slightly_smiling_face:

No need to group, but request needs to match needs :wink:

A 12 branch if for a part he’s not interested on makes no sense.

Makes more sense for .xxx for a couple of cases. And for his need something completely different since no custom strings.

He told me he wanted a way to show the date as MonthName DD, YYYY as per the screenshots he added. (All mockups are his work, not mine.)

If you have another way to make that happen, feel free. I worded the request in terms of features I am familiar with.

The need is localized dates in the about section and your request is a solution for the header.

As the template explains, you requests needs not the solution, specially for this kind of things where the solution does not even cover the need.

Feature requests takes a lot of time to analyze and implement, and implementing things that are actually not needed is just a huge waste of time.

Luckily he posted a screenshot showing that and preventing me to lose time for nothing :wink:

So while I understand why you did it, let people express their needs, not solutions that may not match or that you think could help other future / unknown people, that part is my job :wink:

What part of this refers to a header? I literally said: take the current date format, add month names.

The ability to localize said names is my addition which is beyond the need, but consistent with your implementation when I requested time components.

I apologize for dragging this out but I genuinely don’t see what you are saying about a header.

Where are the custom strings usable ? Only in the header for the subtitle part.

You where one of the good user, please don’t become of the less good.

That was unnecessary, Celorien just added his extra “touch” to this request

Did you really read all the feature requests we did?

Ahhh, okay. Thank you. This is then my fault for splitting the requests up from their original idea.

Let me try to re-explain as a singular idea.

Their overarching idea is to add 1-2 custom string slots to the Album/Artist page as a whole–independent from the existing elements. Their goal for these additional slots was to format the info from the “About” section into a layout of their choosing, complete with tap actions that would behave like tapping the items currently available in the “About” section.

They wanted to also be able to freely arrange these new elements as they see fit (above track list, below it, etc.). That aspect is tied to breaking up the “About” block to arrange those elements individually as well (to allow the existing About sections to be interspersed with the new elements).

Formatting the date to display the month name is an additional component of that request, to more closely emulate how other players handle dates. Whether that is handled as a custom string or as an option for the existing date element was not stated explicitly.

My understanding was that these new string elements that they are requesting, would be used to include the date element instead of relying on the existing “About” section element. Thus a need to add template support to display the months.

So yes let people express their needs themselves please :wink:

In the end it’s a shit ton more to read and analyse and try to guess the actual full need of the user for no benefits.

There’s translations tools everywhere, I do not speak English very well either, and a couple a simple sentences is often better than a novel that distillate the actual data.

1 Like

Yes it was necessary after his last message.

I say it a lot everywhere, time is the most precious thing in life, the one you can’t purchase, what you do with it matters, and loosing time is something I usually hate.

1 Like

That’s why I did all these mockups, the request is simple, bring more features from NPS to Album-Artist page, we show you in all these requests all the new vantages would have Symfonium if you would implement


Original vs Mockup

Please notice how much space I saved with this and not only that, this is more closer to look as music streaming apps, as you well noticed in the NPS share page people wants a familiar look to their favorite streaming app. You can find more vantages in the other request posts :slightly_smiling_face:

1 Like