[Bug fortran/38573] Missing markers for translation

2018-10-05 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/38573] Missing markers for translation

2018-03-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/38573] Missing markers for translation

2017-03-22 Thread fmarchal at perso dot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

--- Comment #13 from Frederic Marchal  ---
(In reply to Roland Illig from comment #12)
> (In reply to Frederic Marchal from comment #11)
> > I suspect a misunderstanding here. Forgive me if I state the obvious.
> > 
> > The fix is not to move the translation mark around.
> 
> I think moving the translation mark "_(...)" into each case of the switch
> statement would solve the problem, so maybe I misunderstood you here.

Ah yes, I see your point. The string literal may be translated with _() when it
is assigned to symstd_msg. It doesn't have to be translated later when
symstd_msg is assigned to symstd.

So moving _() is fine:

  symstd_msg = _("available since Fortran 77");
  if (symstd)
*symstd = symstd_msg;

Sorry, the misunderstanding was on my side. I was stuck with this pattern:

  symstd_msg = N_("available since Fortran 77");
  if (symstd)
*symstd = _(symstd_msg);

[Bug fortran/38573] Missing markers for translation

2017-03-22 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

--- Comment #12 from Roland Illig  ---
(In reply to Frederic Marchal from comment #11)
> I suspect a misunderstanding here. Forgive me if I state the obvious.
> 
> The fix is not to move the translation mark around.

I think moving the translation mark "_(...)" into each case of the switch
statement would solve the problem, so maybe I misunderstood you here.

[Bug fortran/38573] Missing markers for translation

2017-03-22 Thread fmarchal at perso dot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

--- Comment #11 from Frederic Marchal  ---
(In reply to Roland Illig from comment #9)
> (In reply to Jerry DeLisle from comment #7)
> >   /* Otherwise, fail.  */
> >   if (symstd)
> > *symstd = _(symstd_msg);
> >   return false;
> > 
> > Where the mark is on the symstd_msg after it is set to one of the above
> > cases.  Are you saying this does not work?  Does the translation mark need
> > to be on all and not in one place?
> 
> Yes, the translation mark needs to be around each string literal that should
> be translated. xgettext (which extracts the strings from source code) only
> looks at the source code, but never executes the program to see what really
> happens. That's good enough for all practical cases.

I suspect a misunderstanding here. Forgive me if I state the obvious.

The fix is not to move the translation mark around.

String literals must be identified as to be translated by a human translator
(something like symstd_msg=N_("string")) in the source code. Then the string
must also be replaced with its translation at runtime by a call to
gettext(symstd_msg) (usually shortened as _(symstd_msg) by a define).

The above code does call _(symstd_msg) to translate the string at runtime (as
it should) but the string literals pointed to by symstd_msg are not marked as
translatable. Translators never see them. Therefore, when gettext() is passed
the string "available since Fortran 77", it can't find its translation in the
mo file. 

In most cases, the two steps are combined in one call to _("string") that
contains both the string literal extracted by xgettext and the call to
gettext() to actually translate it at runtime.

[Bug fortran/38573] Missing markers for translation

2017-03-21 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

--- Comment #10 from Roland Illig  ---
(In reply to Frederic Marchal from comment #8)
> Adding "is" at the end of the first part works with all the other strings
> that can be inserted at the %s placeholder.
> 
> I can make it work with the French translation too. The German translator,
> Roland Illig, is very active with his translation. I'll CC him to ask his
> opinion about this bug.

It works for German, too. And for Spanish. And probably for many other
languages, since it can be split into a sentence and a subsentence, where the
subsentence does not influence the main sentence. That's seldom for a %s
placeholder, since most others replace only a smaller part of the sentence.

Therefore I think this particular message is no problem, as soon as the texts
for the placeholder are also translated. We still have to be careful with all
the other %s placeholders.

[Bug fortran/38573] Missing markers for translation

2017-03-21 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

--- Comment #9 from Roland Illig  ---
(In reply to Jerry DeLisle from comment #7)
>   /* Otherwise, fail.  */
>   if (symstd)
> *symstd = _(symstd_msg);
>   return false;
> 
> Where the mark is on the symstd_msg after it is set to one of the above
> cases.  Are you saying this does not work?  Does the translation mark need
> to be on all and not in one place?

Yes, the translation mark needs to be around each string literal that should be
translated. xgettext (which extracts the strings from source code) only looks
at the source code, but never executes the program to see what really happens.
That's good enough for all practical cases.

[Bug fortran/38573] Missing markers for translation

2017-03-21 Thread fmarchal at perso dot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

Frederic Marchal  changed:

   What|Removed |Added

 CC||roland.illig at gmx dot de

--- Comment #8 from Frederic Marchal  ---
I hadn't noticed the missing "but is". I automatically understood the message
like this when I read it in my head:

"The intrinsic %qs declared INTRINSIC at %L is not available in the current
standard settings but *is* available since Fortran 77"

Adding "is" at the end of the first part works with all the other strings that
can be inserted at the %s placeholder.

I can make it work with the French translation too. The German translator,
Roland Illig, is very active with his translation. I'll CC him to ask his
opinion about this bug.

[Bug fortran/38573] Missing markers for translation

2017-03-20 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

--- Comment #7 from Jerry DeLisle  ---
intrinsic.c contains a similar error message:

  if (!gfc_check_intrinsic_standard (isym, , false, loc)
  && !sym->attr.artificial)
{
  if (sym->attr.proc == PROC_UNKNOWN && warn_intrinsics_std)
gfc_warning_now (OPT_Wintrinsics_std, "The intrinsic %qs at %L is not "
 "included in the selected standard but %s and %qs
will"
 " be treated as if declared EXTERNAL.  Use an"
 " appropriate -std=* option or define"
 " -fall-intrinsics to allow this intrinsic.",
 sym->name, , symstd, sym->name);

  return false;

The use of the word 'but' here probably should be the start of a new sentence.
In this example parenthesis were not used to enclose the -std= and the
-fall-intrinsics.

Also in this same source file we have:

  switch (isym->standard)
{
case GFC_STD_F77:
  symstd_msg = "available since Fortran 77";
  break;

case GFC_STD_F95_OBS:
  symstd_msg = "obsolescent in Fortran 95";
  break;

case GFC_STD_F95_DEL:
  symstd_msg = "deleted in Fortran 95";
  break;

case GFC_STD_F95:
  symstd_msg = "new in Fortran 95";
  break;

case GFC_STD_F2003:
  symstd_msg = "new in Fortran 2003";
  break;

case GFC_STD_F2008:
  symstd_msg = "new in Fortran 2008";
  break;

case GFC_STD_F2008_TS:
  symstd_msg = "new in TS 29113/TS 18508";
  break;

case GFC_STD_GNU:
  symstd_msg = "a GNU Fortran extension";
  break;

case GFC_STD_LEGACY:
  symstd_msg = "for backward compatibility";
  break;

default:
  gfc_internal_error ("Invalid standard code on intrinsic %qs (%d)",
  isym->name, isym->standard);
}

 --- snip ---

  /* Otherwise, fail.  */
  if (symstd)
*symstd = _(symstd_msg);
  return false;

Where the mark is on the symstd_msg after it is set to one of the above cases. 
Are you saying this does not work?  Does the translation mark need to be on all
and not in one place?

[Bug fortran/38573] Missing markers for translation

2017-03-20 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Frederic Marchal from comment #5)
> This issue is still present in gcc 7.
> 
> The strings assigned to symstd_msg in gfc_check_intrinsic_standard() should
> be marked for translation.
> 
> As it is, the current code in fortran/resolve.c at line 1709 outputs an
> error message containing one untranslated fragment:
> 
>   /* Check it is actually available in the standard settings.  */
>   if (!gfc_check_intrinsic_standard (isym, , false, sym->declared_at))
> {
>   gfc_error ("The intrinsic %qs declared INTRINSIC at %L is not "
>  "available in the current standard settings but %s. Use "
>  "an appropriate %<-std=*%> option or enable "
>  "%<-fall-intrinsics%> in order to use it.",
>  sym->name, >declared_at, symstd);
>   return false;
> }
> 
> I don't know how many languages could work around that string concatenation
> and still present a meaningful message to the user but none can output a
> legible message if %s isn't translated. Therefore, I recommend to mark the
> strings for translation as a stopgap until a full i18n compatible solution
> is available.
> 
> I also suggest to write a comment for translators stating that %s is a
> string such as "available since Fortran 77".

It looks wrong to me here. The "but %s" makes no sense in English. There are
two sentences in the above error message. Do you need the strings split like
this?

   gfc_error ("The procedure %qs declared INTRINSIC at %L is not "
  "available with the current standard setting of %s. "
  "Try a different standard setting option (-std= ) or enable "
  "all intrinsics (-fall-intrinsics).",
  sym->name, >declared_at, symstd);

[Bug fortran/38573] Missing markers for translation

2017-03-20 Thread fmarchal at perso dot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573

Frederic Marchal  changed:

   What|Removed |Added

 CC||fmarchal at perso dot be

--- Comment #5 from Frederic Marchal  ---
This issue is still present in gcc 7.

The strings assigned to symstd_msg in gfc_check_intrinsic_standard() should be
marked for translation.

As it is, the current code in fortran/resolve.c at line 1709 outputs an error
message containing one untranslated fragment:

  /* Check it is actually available in the standard settings.  */
  if (!gfc_check_intrinsic_standard (isym, , false, sym->declared_at))
{
  gfc_error ("The intrinsic %qs declared INTRINSIC at %L is not "
 "available in the current standard settings but %s. Use "
 "an appropriate %<-std=*%> option or enable "
 "%<-fall-intrinsics%> in order to use it.",
 sym->name, >declared_at, symstd);
  return false;
}

I don't know how many languages could work around that string concatenation and
still present a meaningful message to the user but none can output a legible
message if %s isn't translated. Therefore, I recommend to mark the strings for
translation as a stopgap until a full i18n compatible solution is available.

I also suggest to write a comment for translators stating that %s is a string
such as "available since Fortran 77".

[Bug fortran/38573] Missing markers for translation

2009-03-28 Thread fxcoudert at gcc dot gnu dot org


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-28 15:26:01
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573



[Bug fortran/38573] Missing markers for translation

2009-03-28 Thread fxcoudert at gcc dot gnu dot org


--- Comment #4 from fxcoudert at gcc dot gnu dot org  2009-03-28 15:31 
---
Created an attachment (id=17555)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17555action=view)
Proposed patch to fix the main issue

Here's the patch I propose to fix this issue and a few similar ones that grep
revealed. It makes sure the strings can be gathered by xgettext. 

It does not make the logic in intrinsic.c more localization-friendly, because I
think it's far from trivial to do: consider that the string is also returned
from the function where it's emitted, to be used in another error message in
the callee.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573



[Bug fortran/38573] Missing markers for translation

2009-01-03 Thread dfranke at gcc dot gnu dot org


--- Comment #3 from dfranke at gcc dot gnu dot org  2009-01-03 23:58 ---
Also translation related: PR36161.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573



[Bug fortran/38573] Missing markers for translation

2008-12-20 Thread goeran at uddeborg dot se


--- Comment #2 from goeran at uddeborg dot se  2008-12-20 11:26 ---
That's true.  Simply including the is in the symstd_msg, so the entire
message within the parenthesis would be translated as a unit, would be a
significant improvement.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573



[Bug fortran/38573] Missing markers for translation

2008-12-18 Thread schwab at suse dot de


--- Comment #1 from schwab at suse dot de  2008-12-18 23:45 ---
It needs to be rephrased anyway to be i18n friendly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573