Your favorite for declaring string constants in C.

jpollard · 08-01-2016, 03:48 PM

Many/some of them put them in a single file, and make that file a shared library. Using a shared library allows for trivial replacement for a given translation.

Others will still use a single file - but put each translation in a different array element (granted, frequently using pointers), thus one subscript is used for the given translation, the other used for the specific message. The advantage this has is allowing a server to support multiple languages as chosen by the user, rather than as chosen by the installer.

Things get even more complicated when you consider languages also have right to left issues (such as Farsi), and top-to-bottom (Oriental languages, which may have both issues), along with various alignment issues.

It also changes things if you are using a GUI, as the message may need to be part of a data structure containg a given starting location...(sometimes even font sizes).

Michael Uplawski · 08-01-2016, 03:50 PM

The original question was (and this is documented): “There is plenty of info about string constants in C. But I am interested to know which one do you find yourself using most often?“

An answer like “I think neither of them are any good” does not appear to relate.

Furthermore, any such string may serve in only 1 place and be used exactly once during the execution of the program, depending on the conditions which may alter for each execution. The point of a constant is not to provide one and the same string for many uses, but to liberate the programmer. The difficulties with gettext are difficulties with gettext, not with string-constants. For my ruby programs, I use a translation mechanism which does, for example, not bother if a string is defined in a string-constant or ad hoc and in place, but I would not call that an amazing Ruby-magic.

Michael Uplawski · 08-02-2016, 02:53 AM

Quote:

Originally Posted by Michael Uplawski

Good eyes, anyway.

To make the constant pointer to a mutable string a (constant) pointer to a constant string, move the const keyword to the right of the * operator. With the three possible positions of the const keyword, some permutations are possible.

There should be a good explanation in The C-Book, but it contradicts my statement above, as well as my observation. Using gcc 5.4.0, I achieve that only the attempt to alter a char * const variable value fails:

Code:

#include <stdio.h>

int main(int argc, char ** argv){
	const char * cp = "Something with const in front";
	char * const cpd = "const after *";

	printf("cp is %s\n", cp);
	printf("cpd is %s\n", cpd);

	// works as expected
	cp = "Something else for cp";
	printf("new cp is %s\n", cp);

	// fails as expected
	cpd = "cpd has been changed";
	printf("new cpd is %s\n", cp);

	return 0;
}

And I want to thank the OP for this thread, btw.

Guttorm · 08-02-2016, 02:57 AM

Well I guess defining string literals in one file sometimes is a good solution, but I think not always. I think I have written all 3 kinds one time or another. And I've also translated a few times. I guess I was thinking the words could change depending on conditions wich may alter for each execution or compilation. So I made something like a "constants.h" file.

But when translating, those conditions didn't change. It's not like I would compile or make a Norwegian version, and use #ifdef or other ways to set the values. I used a tools that scan thru the code, looking for things that needs translation. And the translations are put in seperate files - I didn't change the constants.h file. And last time I did it, it would for example tell me that "Game Over Man" in constants.h - line 123 needs translation.

To translate well, you need to know the context where the words are used. So I could look at constants.h and then grep for GAMEOVER. Not a big problem, but it's even more difficult with generic words that are defined once and used in many places.

So that's why I think sometimes "none of the above", is a better solution. They sometimes just complicate things, and make grepping in the code more difficult.

Michael Uplawski · 08-02-2016, 03:06 AM

Quote:

Originally Posted by Guttorm

To translate well, you need to know the context where the words are used. So I could look at constants.h and then grep for GAMEOVER. Not a big problem, but it's even more difficult with generic words that are defined once and used in many places.

We put translating spoken language in the programming context, where it does not belong, in my opinion. Two ways of achieving a good translation are possible: Someone scans the code and uses his language skills to provide alternative translations. This is improbable for most languages.

Or you have tools which do it for you. The only time, that I used such a tool (of Norwegian origin), it offered me a view on the context of a phrase to translate and a list of occurrences of the same expression. This gives me a perspective and allows anybody with sufficient language-skill to do the translation.

My own technique is externalizing just all strings into a yaml file, from where they are eventually read during the execution of a program. I automated all of it and also get hints on missing translations.

In summary, I consider the production of language-versions of my programs a task outside the scope of coding. The language tools must be able to work with existing code, not the inverse.