You could use :GetPropertyChangedSignal
on the Text
property which should be pretty much the same (unless you add an empty tag for some reason).
Nonetheless I still prefer having it as a property
RenderedText
was (unsurprisingly) considered as one of the options.
The reason that we didnât go with that one is that it has a strong implication that the property only works when the text is actually being rendered to the screen. Which is not the case, you can read the ContentText
property and use its value even for an Instance that isnât parented to the hierarchy.
Perhaps then a better solution would be to introduce extra specificity? ContentText
as-is is still relatively vague. What about a name such as RichTextContent
?
Including RichText specifically in the naming is also undesirable in some ways, because while RichText is currently the only way for the Text property and the actual processed text to mismatch, there may be other ways for that to happen at some point in the future, and it would be nice for this property to also interact well with those.
Though obviously including a reference to RichText in the naming would make it more clear for the time being, so itâs a tradeoff.
If Iâm not wrong, this read-only value is a string? If so, why not call it âTextContentsâ or âContentsOfTextâ or something that is a bit more specific. I can see how coming up with a name for this was difficult, because It took me a good while trying to think of a good name for it.
In general my thoughts were:
- TextVolume
- TextDetails
- TextCapacity
- TextSum (More for something like numbers so I didnât quite know how I felt about this one)
Anyways thatâs all the name ideas I had. Hopefully that helps generate a new name for it, because I feel like âContentTextâ is just something that is way to generic and thatâs definitely a name that tons of people (myself included) probably used at some point.
Maybe make some sort of engine warning to the user who attempts to use a Child that is named âContentTextâ directly through the .
navigation instead of :WaitForChild()
and :FindFirstChild()
?
Anyways good update. (I think?)
What do you mean by this? Itâs just the text?
What they mean is, if someone uses something like RichText to achieve like line breaks and stuff like n/
,
it would be like Hello world
(2 spaces inbetween Hello World
while not using RichText, it would only have 1 space. Itâs to show the accurate string over the normal Text property. I feel itâs a bit redundant as well, but I think this is what they mean.
If the RichText is on, It would return you the string with all the rich text tags removed. When the RichText is off it will be equivalent to Text.
What about something like RawContentText, CurrentDisplayedText, or CurrentContentText? Something more specific that would be less likely to cause things to break.
In addition to ignoring formatting tags, does this also return the text displayed after localization?
I second this! Emphasizes it as being readonly.
Your suggestion would not produce the same effect.
Say I wanted to play a typewriter sound whenever a letter is added. Binding it to changes of the Text
property would cause it to play even when a new character was not displayed, because a RichText tag was added.
Considering this shows the currently rendered text, it must display whatever is being shown to the user. This means it must show the localized text, if it is being used.
You could just use MaxVisibleGraphemes for this, by the way.
Will this also show localized text?
RawText? VisibleText? ProcessedText? StringText? NoMarkdownText? RealText? TranscriptText?
ContentText makes no sense because the content of the text is whatâs contained in it, not just whatâs visible. Also, even one of the staff members seems to have gotten the name confused:
which shows itâs just going to lead to confusion.
Fear not, I use Dvorak keyboard layout where T and N are right next to each other, so that was just an unfortunate typo:
Though to be fair staff will occasionally get stuff like this wrong because they remember a previous iteration of an API where the name changed around a few times in development.
This will be the raw string in the original language without format tags, without the effect of MaxVisibleGraphemes. We already have a property on TextObject called LocalizedText
, you can check about it here: TextLabel | Roblox Creator Documentation, this will show you the string after localization if you are using AutoLocalize Property.
The original plan for having this property on TextObject is mostly for filtering/localization purpose. ContentText is the text we are going to use to send to localization if you are using AutoLocalize Property. If you would like to localize string with rich text tags preserved, you would need to use a key-based translation table through system and manual apply localized string to text, in which case this new property will return you the localized result without tags.
Example
Currently there are 2 ways of localize a RichText string. If you are using AutoLocalize, a label with the following text property:
This will be <b>auto-localized</b>.
will be auto-localized using:
This will be auto-localized.
Which means it looks up in localization table with the ContentText as source string in the original language. In this case the LocalizedText will return the localized result.
if you want to preserve tags, it would need to turn off AutoLocalize, and have code that does:
local keyTranslation = translator:FormatByKey("TagsPreserved")
textLabel.text = keyTranslation
and make the source string for localization key TagsPreserved :
This will be <b>auto-localized</b>.
In this case the ContentText will return the localized result. (As you are localizing it by directly modify the original string.)
This post is mostly for informing about the upcoming change, the release does not directly enable the feature itself until we turn on the feature on production. Before that you would not get valid result from this new property. And we will adapt feedbacks here if necessary.
While I understand this property name probably came from JavaScriptâs .TextContent property, Iâm not convinced Roblox should copy this naming convention.
The only reason why this is called .TextContent is named such in JavaScript is because .Content is the html property to write the raw values of markup. In Roblox, the raw value is .Text, so I would much prefer .PlainText or even .RenderedText (even if it may appear the content has to be visible). I think .ContentText just feels a bit weird.
Anyway, either way, it really doesnât matter. Thanks for not breaking main UI layouts without .Content as the primary name.