Unused and missing strings + suggestions

[ThierryC]

Hello,

I have the impression that some strings (maybe many) are not used anymore or are duplicated (for the main site). Am I correct? Do the admins have a (simple) way to check and remove the unused ones?

Also: I can imagine it's not straightforward to implement; but it would be useful to have a way to see how the strings are connected together. We can wait 24 hours for the update, but that is inconvenient, and sometimes it takes time to find a particular string and condition. For instance, a dummy version of the site with "reverse links" (best) or some kind of "tree structure" would be helpful.

Last but not least: there are many missing strings (i.e., not available for translations). I reported some in the corresponding topic, but I wonder whether they are dealt with. As far as I understand, Een is the only person who manages missing strings. I think the community could better help if there was a tool for this. Maybe something like the bug report.

What do you think?

[LightKnight]

I think many translators would agree with ThierryC about the great improvement it'd be to have links or anything to help us know where in the site the string is from. I do.

[Een]

Hello!

I have the impression that some strings (maybe many) are not used anymore or are duplicated (for the main site). Am I correct? Do the admins have a (simple) way to check and remove the unused ones?

Strings to translate are extracted from the code.
Over time, some code may not be used anymore but the strings will remain unless they are removed from the code. Unfortunately, I cannot think of any efficient way to check for those. Still, duplication should not occur since when two indentical strings are marked for translation we consider it the same and it appears only once (but of course, if there is just a slight difference such as a typo, it will appear twice).

Also: I can imagine it's not straightforward to implement; but it would be useful to have a way to see how the strings are connected together. We can wait 24 hours for the update, but that is inconvenient, and sometimes it takes time to find a particular string and condition. For instance, a dummy version of the site with "reverse links" (best) or some kind of "tree structure" would be helpful.

Not sure what you mean by "tree structure", but there is no hierarchy applicable to translatable strings.
What I would like to do someday is "in place editing" meaning you toggle a "translator" option somewhere and any translatable string gets an "edit" icon in the same spirit of your reverse link but without the need to open another page. But this is indeed not straightforward to implement (not even sure it's completely doable). But well, maybe someday I'll get the time to work on that: it would be really nice if it can be done.

Last but not least: there are many missing strings (i.e., not available for translations). I reported some in the corresponding topic, but I wonder whether they are dealt with. As far as I understand, Een is the only person who manages missing strings. I think the community could better help if there was a tool for this. Maybe something like the bug report.

Well, currently they are not adequately dealt with. Someone requested that sticky thread and I thought it was a good idea, but in fact it was not, since it's the developer for the game that can the most easily fix missing strings, and that developer doesn't necessarily read the forums. When I get some time to spend on translations I mean to add an option to report missing strings to the bugs section and to close that forum thread.

[ThierryC]

Hello Een,

Thanks for your answer!

Strings to translate are extracted from the code.
Over time, some code may not be used anymore but the strings will remain unless they are removed from the code. Unfortunately, I cannot think of any efficient way to check for those. Still, duplication should not occur since when two indentical strings are marked for translation we consider it the same and it appears only once (but of course, if there is just a slight difference such as a typo, it will appear twice).

Thanks for these clarifications. I see a bit better how it's done.
However, when/how are the strings compared for equality? I'm asking because I've seen for example twice "Your e-mail". Also, I can imagine situations where in one language it's OK to have the same string, whereas it's not the case in some other(s).

Not sure what you mean by "tree structure", but there is no hierarchy applicable to translatable strings.
What I would like to do someday is "in place editing" meaning you toggle a "translator" option somewhere and any translatable string gets an "edit" icon in the same spirit of your reverse link but without the need to open another page.

That would be really nice indeed!
Actually, I realise that what I have in mind with the "tree structure" is probably even more complicated to implement. I understand there is no clear hierarchy. I was mostly thinking of instances which are linked to each other through a marker (${}), when this marker is actually a string itself.

[...] since it's the developer for the game that can the most easily fix missing strings, and that developer doesn't necessarily read the forums. When I get some time to spend on translations I mean to add an option to report missing strings to the bugs section and to close that forum thread.

That would be nice. In the meantime, would it be acceptable if we send a private message directly to the relevant developer?

[Een]

However, when/how are the strings compared for equality? I'm asking because I've seen for example twice "Your e-mail". Also, I can imagine situations where in one language it's OK to have the same string, whereas it's not the case in some other(s).

First step is gathering strings; then, inserting them in the database if they don't exist there. It's on this second step that deduplication occurs.
For "Your email" it's actually "Your email " and "Your email". There is only one space more in one string, but still, those are different strings just like if someone had made a typo. It shouldn't occur very often.

Actually, I realise that what I have in mind with the "tree structure" is probably even more complicated to implement. I understand there is no clear hierarchy. I was mostly thinking of instances which are linked to each other through a marker (${}), when this marker is actually a string itself.

Well, ${} markers are substitution variables, and the principle is that they can be substituted by... anything
So there are no dependencies between strings (except if the developer explicitly reported them somehow, but that would need an extra layer of abstraction that would be more cumbersome than useful).

That would be nice. In the meantime, would it be acceptable if we send a private message directly to the relevant developer?

Well, I don't see why not. You should be aware, though, that some developers may not be active anymore and so may not respond.

[ThierryC]

For "Your email" it's actually "Your email " and "Your email". There is only one space more in one string, but still, those are different strings just like if someone had made a typo.

On my side, I can't see a difference (extra space) between these two strings (in English).
I'm not saying those in particular should be merged; just that I cannot see the difference.

[quote="Een"Well, ${} markers are substitution variables, and the principle is that they can be substituted by... anything [/quote]
Oh OK. I thought that some strings were reused in others to enforce some consistency among strings.

Thanks.

[Een]

On my side, I can't see a difference (extra space) between these two strings (in English).
I'm not saying those in particular should be merged; just that I cannot see the difference.

"Your email " has a space trailing after email, while "Your email" doesn't. Small difference, but sufficient, since for a computer a space is a character like any other

[ThierryC]

On my side, I can't see a difference (extra space) between these two strings (in English).
I'm not saying those in particular should be merged; just that I cannot see the difference.

"Your email " has a space trailing after email, while "Your email" doesn't. Small difference, but sufficient, since for a computer a space is a character like any other

I understood what you meant. What I meant is, I can't see this extra space when selecting the text (whereas I can see such as trailing space in other similar instances). Strange. But anyway, not a big deal.

[Liallan]

What I would like to do someday is "in place editing" meaning you toggle a "translator" option somewhere and any translatable string gets an "edit" icon in the same spirit of your reverse link but without the need to open another page. But this is indeed not straightforward to implement (not even sure it's completely doable). But well, maybe someday I'll get the time to work on that: it would be really nice if it can be done.

I don't know that I'm understanding this. So I'll explain what I think you mean. Like I go to the new community page and there's a box about adding friends, and it says "Why adding friends?" and I think, that's not right. So some place there's a thing I can click that turns on an in-screen editor, so I then go back to where it says "Why adding friends?" and edit it right there on the page. Is that what you're meaning?

I can see the "handiness" of that. But you linked to this post when someone was asking about context, and I'm not seeing how that helps this problem. It helps not have to open a new page to get to the translator and search, which I don't really mind doing. (New pages don't bother me - it's scrolling I don't like. ) But either way, you're translating while you're looking at the context, which still does not find the context when you're in the translator. And I guess I thought that's what you were trying to solve?

I get that context is a tough one.

[Een]

What I would like to do someday is "in place editing" meaning you toggle a "translator" option somewhere and any translatable string gets an "edit" icon in the same spirit of your reverse link but without the need to open another page. But this is indeed not straightforward to implement (not even sure it's completely doable). But well, maybe someday I'll get the time to work on that: it would be really nice if it can be done.

I don't know that I'm understanding this. So I'll explain what I think you mean. Like I go to the new community page and there's a box about adding friends, and it says "Why adding friends?" and I think, that's not right. So some place there's a thing I can click that turns on an in-screen editor, so I then go back to where it says "Why adding friends?" and edit it right there on the page. Is that what you're meaning?

Yes, exactly.

I can see the "handiness" of that. But you linked to this post when someone was asking about context, and I'm not seeing how that helps this problem. It helps not have to open a new page to get to the translator and search, which I don't really mind doing. (New pages don't bother me - it's scrolling I don't like. ) But either way, you're translating while you're looking at the context, which still does not find the context when you're in the translator.

Well, yes, that's correct.

And I guess I thought that's what you were trying to solve?

Actually no, because I don't think that this can be solved. There is no way to go to the appropriate page directly from the translator, since the pages use the strings, but the strings don't know which page (or pages) will use them (and considering the dynamic nature of the website, creating this information by analysing the code would be really difficult even if possible).

The in place editor would be convenient, and maybe replace the current translator as the favourite way of translating (translators could just use the site then when seeing an untranslated string, toggle translating to translate it). So it would be more a workaround than a solution to the absence of context in the current translator, and an easy way to fix mistakes when chancing upon them. But in essence, like you said it would be the same as opening a new tab to the translator to search for the string.