►
From YouTube: SIG Docs monthly localization meeting for 20201207
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello:
everyone
welcome
to
the
december
7th
meeting
of
the
kube
sig
docs
localization
subgroup.
A
This
meeting
is
being
recorded
and
we
do
ask
that
you
follow
the
cncf
code
of
conduct
and
I'd
like
to
welcome
everyone.
Just
some
small
upfront,
ish
things
that
we've
taken
care
of.
Hopefully
you've
seen
that
we
have
gotten
the
calendar
meeting
time
now
at
the
proper
time,
so
it
does
match
when
the
meeting
is
being
held
thanks
to
jim
engel,
for
for
helping
to
get
that
fixed,
so,
hopefully
you're
now
seeing
the
the
1500
utc
time
slot
on
your
calendar.
A
We've
got
several
great
topics
today
and
let
me
go
and
put
in
the
chat
window
if
you
don't
have
the
doc,
but
that
is
where
you
can
find
our
agenda
and
we
could
start
with.
Is
there
anyone
that's
new
to
this
feeling
that
hasn't
attended
before
so?
Are
there
anyone
that's
new?
I
know
jerry's
been
here
before.
Obviously
irving's
been
here
before
soccer's
been
here
before.
A
A
A
All
right-
and
so
I
can
go
ahead
and
share
my
screen,
so
we
can
see
the.
A
A
Share
and
so
if
we
see
everybody's
starting
to
put
their
names
in,
which
is
great.
A
And
so
the
first
topic
that
we
have
on
the
agenda
came
into
jim
angle,
from
kaiming
regarding
localization
partial
updates.
So
kaibing
did
you
want
to
take
some
time
and
explain
what
this
issue
was
and
the
concern.
B
Absolutely
so
here's
the
thing
we
all
know
the
whole
kubernetes
website
is
changing
every
day,
every
single
day
for
every
release.
We
got
new
contents,
we
deprecate
old
ones,
the
for
localization
teams
such
as
chinese
localization
team.
We
have
been
working
very,
very
hard
to
keep
everything
updated
and
so
far
until
verse,
9
1.19.
B
So
with
that
shift
of
focus,
we
will
need
to
make
sure
we
are
tracking
accurately
every
changes
happening
in
the
english
version.
B
So
the
way
we
are
doing
that
is
using
a
script
you
can
find
under
the
scripts.
Subdirectory
is
called
lsync
dot
sh,
using
that
script
we
can
find
which
page
which
english
page
has
changed.
B
B
B
Hello,
I'm
back.
Okay,
keep
going
okay,
so
so
we
are
trying
to
keep
the
chinese
localization
as
new
as
possible.
So
the
way
we
are
doing
that
is
to
compare
the
changes
made
it
made
since
the
last
time
I
see
a
certain
page
has
been
translated
or
updated.
B
B
B
B
B
A
Yeah,
let
me
see
if
I
can
play
it
back
to
you.
I
think
it
comes
down
to
if
someone
doesn't
do
a
full
page
translation,
but
just
does
say
a
typo
fix
pr
on
a
already
translated
chinese
page.
A
C
A
B
Right
right
exactly
so
so
for
that
reason,
because
our
focus
for
the
next
release
would
be
keep
everything
up
to
date,
so
we
proposed
an
item
in
the
chinese
localization
style
guide
to
how
people
understand
the
reason
we
made
this
decision
and
how,
when
we
are
having
some
questions
from
the
team,
we
just
point
people
to
that
paragraph.
Read
it
and
these
questions,
if
any
so
so
that's
all
an
update,
maybe
this
can
be
applied
to
other
localization
teams.
Maybe
it's
not
applicable.
B
I
just
don't
know
so.
I
brought
up
this
change
to
chinese
localization
style
in
our
previous
meeting.
So.
A
So
so,
if
if
I
come
and
I
decide
if
so,
if
I
I
see
a
page,
a
chinese
page
and
I
see
a
typo
and
I
want
to
submit
a
pr
to
fix
the
typo,
my
guess
is
the
reviewer
should
respond
and
say:
I'm
sorry,
you
have
to
do
a
full
update
of
the
entire
page,
because
if
you
don't
do
that,
it's
going
to
cause
us
problems.
So
in
that
case,
do
you
you
don't
merge
the
pr
do
you
you
ask
the
person
to
either
translate
the
full
page
or
close.
The
pr
is
that
correct.
B
Yes,
during
the
first
few
days,
we
encountered
some
some
questions,
some
suggestions,
but
after
we
explained
the
reason
behind
this
change,
people
are
okay
with
the
change
so
because
we
have
already
translated
all
pages
from
english
version,
the
synchronization
for
the
most
of
the
time.
It's
not
a
big
deal,
that's
a
few
lines
of
editing
gotcha,
so
so.
A
B
A
And
so
this
is
now
the
best
practice
from
the
chinese
localization
team,
and
it
sounds
kind
of
like
climbing
you're
saying
this
this
this
new
best
practice
is
working
very
well
and
you're
you're,
bringing
it
up
because
we
think
the
other,
the
other
teams
may
benefit
from
this
best
practice.
Is
that
correct.
B
B
But
if,
if,
for
example,
a
team
is
working
on
not
the
latest
version,
for
example
today,
if
a
localization
team
is
still
working
on
version
1.18,
so
they
they
won't
have
such
a
problem
because
release
18
is
stamp
shorted.
It's
pretty
stable,
yeah.
A
Okay,
that's
another
great
excellent
point:
that's
a
wonderful
insight.
So
this
issue
is
really
when
you
finally
caught
up
to
being
on
the
latest
version.
This
is
when
you're
going
to
run
into
this
issue,
but
if
you're
running
on
a
previous
version,
you
don't
have
to
worry
about
this
best
practice
because,
like
you
said
it's
snapshotted
and
and
there's
no
harm
in
fixing,
say
typos
right.
A
That
is
really
really
insightful.
That
is
so
cool,
so
those
two
factors
together
seem
to
make
a
really
good
best
practice.
Any
thoughts
from
everyone
else
on
the
call.
What
a
great
topic
coming!
Thank
you
for
bringing
it
to
the
group.
D
I
have
questions
about
this
so
doing
that
kind
of
perform
like
a
periodic
job
through
pro,
to
check
this
kind
of
whether,
like
the
last
the
last
translated
pages
from
english
to,
for
example,
in
other
localizations
teams,
or
what
kind
of
approach
that
you
want
to
do,
or
have
for
this
kind
of
like
just
to
make
sure
that
we
don't
input
partial
changes
to
original
pages
that
actually
been
deleted
or
removed.
B
Page
deletion
and
the
id
of
new
pages
happened
very
rare
today,
for
most
of
the
upstream
prs
is
about
some
copy
editing.
Some
some
bug
fixing.
D
You
do
that
in
in
like
github
actions
or
something
like
that,
so
that
when,
when
someone
perform.
B
B
I
will
keep
my
local
branch
updated
to
the
master,
so
so
I
will
check
everything
on
master
and
see
if
there
are
some
remaining
changes,
not
well
synchronized.
I
will
remind
the
pr
committed
contributor
to
do
that
and
this
practice
has
been
communicated
throughout
the
chinese
localization
team.
A
So
so
coming,
it
sounds
like
you
have
a
process
in
place
to
to
effectively
perform
the
best
practice,
and
it
involves
the
steps
of
keeping
the
keeping
the
branch
up
to
date.
So
you
can
do
the
proper
checks
for.
A
Sure,
but
you
know
the
idea
would
be
to
document
this
somewhere
for
other
teams
just
so
they
know
how.
A
E
B
E
B
A
B
The
the
actual
requirement
for
future
exchange
tracking-
and
here
is
the
script.
If
you
run
this
script,
followed
by
your
class
page,
we
will
see
the
difference
made
since
the
last
time
you
have
translated
or
uploaded
updated
your
localized
page.
If
you
replace
the
js
here
with
your
language
code,
the
script
still
works.
B
A
B
A
B
A
B
A
Yeah,
that
would
be
wonderful,
I'd,
be
happy
to
give
you
a
timely
review
and
approve
climbing.
That
would
be
fantastic
because
it's
such
a
valuable
tool,
the
the
lsync
right.
It
shows
you
all
the
changes,
and
now
you
have
an
understanding
of
how
to
use
it
when
you're
all
the
way,
updated
and
you're
current
and
what
you
can
use
it
and
when
it's
safe
to
just
fix
typos,
if
you're
on
a
on
a
snapshot
at
back
level.
So
it
seems
like
it's
a
really
proven
best
practice.
Timing.
A
C
Yes,
actually
clientele
also
have
they
also
use
similar
scripts.
As
I
mentioned
the
in
the
previous
meeting.
C
C
Also,
I
think
in
this
script
directory.
Maybe
I
can
share
my
screen.
Can
I
share?
Is
it
okay
to
share
sure
sure.
C
C
The
script
generates
a
report
of
outdated
content
in
contents,
localization
language
directory
by
comparing
two
localization
team-
milestone
branches
it
just
if
we
run
this
script.
C
C
C
This
this
is
actually
covered
for
changes
and
if
you
check
those
korean
content
updates
is
for
keep
up
with
the
upstream
range.
So
we
are
doing
this
job
for
every
table
branch
is
initiated,
so
maybe
it
is
a
little
bit
different
with
chinese
localization
team.
I
think
chinese
localization
team
use
timestamp
method
which
korean
team
does
not
have,
but
we
only
update
after
around
two
weeks
or
three
weeks,
job
so
in
case
of
chinese
localization
team.
C
As
keeming
said,
every
review
or
approver
needs
to
check
whether
the
changes
are
updated
or
up
to
date,
or
not
so
maybe
localization
themselves
in
different
in
case
of
korean
locality,
localization
team,
we
we
still
have
some
documents
which
are
not
translated
yet
so
we
don't
need
to
keep
up
to
date
for
that
document,
since
we
don't
provide
translated
documents
yet
so,
if
we
cover
four
documents-
and
I
think
chinese
localization
teams
approach
seems
nice,
but
in
stage
of
korean
organization
we
prefer
this
way.
A
C
C
C
Someone
tried
to
update
this
link
for
only
for
korean
document
and
you
don't
accept.
We
check
the
english
document
and
we
check
whether
the
english
document
already
changed
or
not.
If
it
is
not,
then
you
don't
accept,
so
we
keep
the
with
try
to
korean
content.
Try
to
follow
the
english
content,
always
follow
the
english
content.
A
A
B
A
A
If
you're
you
know
doing
the
batch
based
approach,
you
might
want
to
do
use
these
tools.
If
you
have
a
very
significant
effort
and
you're
you're
able
to
pretty
much
keep
everything
translated.
Well,
you
might
want
to
use
the
other
tools.
I
I
think
that's.
The
challenge
is
just
to
kind
of
get
that
documented
in
the
in
the
docs
to
say.
Here's
when
this
approach
is
good
and
here's
when
the
other
approach
is
good,
I
think
that's
what
would
be
most
valuable
to
the
other
localization
teams.
Does
that
make
sense
that
makes.
B
C
A
E
So
for
japanese
team-
oh
hello,
yes,
please
go
ahead,
so
we
have
made
our
own
script
based
on
golang,
but
it
it
kind
of
relies
on
the
github
api,
which
is
relatively
heavy
and
I'm
actually
I've.
I
actually
just
used
the
korean
script
and
it
it
only
uses
the
python
and
the
git
command
and.
A
E
Definitely
yeah
only
I
need
to
be
careful
about.
You
know
the
difference
of
the
the
translation
work,
because
you
know
obviously,
japanese
team
and
the
korean
team
has
like
a
different
schedule
for
milestone
and
also
like
a
different
target
a
little
bit
as
in
like
the
branch
strategy
and
such
so
yeah.
I
have
to
be
careful
about
that,
but
still
this
tool
should
be
really
useful.
A
Yeah
very,
very
exciting,
okay,
so
kaiming,
I
think
we've
covered
your
topic
fully.
It
was
a
great
topic.
E
Yeah,
I
I
I
can
talk
so
this
was
actually
me
and
ivy
yeah.
So
so
this
pro
request
in
the
link
basically
provides
context,
and
I
I
can
share
the
screen,
quick,
quick.
E
Sure
do
you
see
my
skin?
Yes,
okay,
so
yeah,
here's
the
pull
request,
and
this
is
just
a
typo
fixing.
I
forgot
oh
yeah,
so
here's
the
typo
in
here-
and
you
know
this
is
japanese.
E
So
I
consider
this
kind
of
per
request,
even
if
it's
just
a
slide
typo,
because
it
doesn't
include
any
english
letters
such
as
like
if
there
was
a
typo
in
endpoint
slice.
I
I
I
would
say
it's
fine
to
be
reviewed
by
any
other
languages
people,
but
because
it's
it's
a
typo
for
the
japanese
language,
specific
specific
topic.
E
I
asked
avi
not
to
give
unapproved.
Just
please
give
lgtm
if
you
feel
it's:
okay,
yeah!
That's
that's
what
happened
here.
E
No,
I
mean
one
reviewer
got
lgtm
yeah,
but
we
tend
to
be
careful
about
merging
progress.
At
least
we
need
more
than
two
peoples
like
lgtm
or
uproof
from
japanese
side,
okay
yeah.
So
we
want
to
follow
the
rule
so
yeah.
E
A
E
Yeah
yeah
yeah
2ljtm
by
japanese
reviewers.
That
would
be
fine
for
merging
for
request
because,
like
for
example,
if
I
make
a
pull
request
by
myself
right
and
we
have
two
owners
that
who
has
who
have
review
permission,
I
know
I
mean
merge
permission
so
like
I
sometimes
merge
my
pull
request
by
myself
by
giving
approve
right,
but
I
still
wait
at
least
for
two
reviewers
to
give
lgtm.
A
And
then
so,
irby
was
thinking
of
a
a
different
solution.
It
looks
like
to
to
to
to
solving
the
problem.
Is
that
right,
rv.
D
Yeah,
so
basically
do
you
have
some
kind
of
rules
on
this?
Maybe
we
can
kind
of
check
the
rules
here,
so
this
kind
of
things
doesn't
happen
again
in
future,
and
I
want
to
say
sorry
because
I
came
with
japanese.
So
that's
why
I
just
approve
it,
but
I
noticed
that
this
is
not
really
a
good
example
of
doing
that.
So
I
was
thinking
if
it's
possible
to
kind
of
separate
the
owner
and
admin
for
each
localization.
D
So,
even
though
you
are
like
the
owner
of
the
whole
repo,
you
can
still
merge
it
unless
the
localizations
is
already
approved,
that
specific.
E
Pr
yeah,
while
I
understand
what
he's
saying,
but
it's
kind
of
too
specific,
because
you
know
when
it
comes
to
english,
it
means,
like
you,
have
permission
for
everything
like,
including
like
slash
localization
in
the
directory,
for
example.
Right.
So
like
oh
this
one
I
18n
so
for
each
language.
E
It
applies
only
here
right
when,
when
you
have
english
merge
permission,
you
have
permission
for
everything
right.
That's
the
current
status.
C
I
think
I
think
we
just
need
a
guideline,
maybe
even
though
english,
if
even
if
wait,
wait.
E
I
guess
so
I
I
think
it
makes
sense.
They
have
all
permissions,
then
for
sure.
A
E
C
A
We
just
have
to
educate
that
small
team
to
say:
hey,
wait
for
two
lg
tms
and
and
not
someone
like
brad,
who
shows
up.
You
know
and
shows
up
and
goes.
Oh
I'll
approve
this
right.
That
doesn't
so.
So,
if
that's
the
case
irving,
then
it's
probably
just
a
a
a
matter
of
educating
the
sig
doc
leads
and
we
probably
have
a
simpler
solution
that
that
probably
will
be
okay
called.
D
You
please
link
the
rules
for
your,
I
mean
for
your
localization
team
here,
so
I
can
take
a
look
into
that
either.
E
Oh,
I
mean
we
did
not
have
any
specific
rules
for
that
specifically,
but,
like
you
know
in
general,
when
you
try
to
give
an
approve
on
something,
you
have
to
have
the
responsibility
on
what
you're
doing
right.
So
I
think.
E
It's
more
like
that,
I
mean
making
rules,
make
everything
more
strict,
so
I
personally
don't
really
like
it.
I
mean
yeah
as
long
as
it
makes
sense
it's
okay,
but
for
this
specific
case,
I'm
not
sure
if
making
another
rule
is
a
better
solution
for
this.
A
But,
but
how
do
we
keep
it
from
happening
again?
So
if
the
situation
comes
up
again,
is
it
just
irve
should
never
do
an
approve
for
a
japanese
pr
fix?
Is
that
what
is
the
the
proper
way
to
to
to
fix
this
going
forward?
B
It
doesn't
happen
again
so
so
here
it
is
so,
to
be
honest,
I
have
been
with
the
signals
team
for
about
three
years.
I
rarely
see
this
thing
happen.
If
we
really
see
such
a
hype
accident.
A
B
A
D
Yeah
so
if
let's
say
we
have
a
specific
for
each
localizations
team
on
how
we
can
kind
of
review
that,
because
you
know
like,
for
example,
I
won't
mean
like.
I
can't
review
the
pr,
because
I
can't
read
japanese,
but
it
doesn't
mean
that
I
have
the
full
control
of
approving
that
and
I
realize
that's
wrong.
D
D
I
know
because
I
mean
if
let's
say,
the
localizations
team
is
only
having
like
two
owners
or
something
like
that.
Then
it
will
be
more
easier
for
us
to
communicate
to
each
other.
But
if,
let's
say
the
localization
team
is
quite
large,
then
maybe
we
we
will
need
such
a
rules.
I
I'm
not
sure
actually,
but
that's
what
I
found.
A
Well,
I
would
say
it
a
little
bit
different.
You
know,
I
know
for
the
english,
we
we
talk
about
the
process,
for
what
an
approval
is
done
or
how
how
an
approval
occurs,
and
it
sounds
like.
Maybe
if
the
japanese,
in
in
the
japanese
page,
said
here's
how
our
approval
process
was
done.
Maybe
you
would
have
seen
that
and
said?
Oh,
I
shouldn't
approve
this
because
now
I
realize
it's.
Their
standard
process
is
two
lgtms,
so
does
that
make
sense
or
no.
A
I
think
I
think
timing
is
right
either
way.
This
is
very
rarely
going
to
happen
because
I
mean
look.
Look
what
keys
had
to
turn
one
irve
can
read
japanese,
which
I
did
not
know
good
to
know,
reads:
japanese
and
she
had
authority
at
a
high
level,
so
the
odds
of
people
having
those
two
keys
to
be
able
to
turn
and
and
and
cause
this
to
happen.
There's
probably
not
a
lot
of
people
in
our
community
like
that.
A
As
my
guess,
I
could
be
wrong
with
great
power
comes
great
responsibility,
rv
having
approvals
and
the
ability
to
read
other
languages.
That's
that's
very
impressive.
D
Yeah,
I
just
want
to
make
sure
that
this
kind
of
things
doesn't
happen
again
in
the
future.
So
if
we
have
some
kind
of
rules,
maybe
I
can
read
thousand,
but
with
your
comments
of
like
you
need
only
like
lgtf,
if
you
think
it's
like
good
for
you
or
things
like
that,
then.
E
D
E
A
E
E
D
A
Soca,
the
next
topic
is
yours.
Yes,.
C
I
just
hope
to
share
that
there
are
some
localization
related
files
which
we
don't
korean
localization
gives
does
not
have
does
not
have
ownership.
Yes,.
C
I
agree
you're
looking
up
yeah
this
website,
I
18n
directory.
There
are
a
toml
part
for
every
localization
languages,
but
in
case
of
this
directory
in
case
of
this,
I
we
don't
have
ownership.
Localization
team
does
not
have
ownership.
So
when
we
try
to
change
this
pipe,
then
we
we
need
to
retest
a
problem
from
the
english
owner,
maybe
not
english
owner
or
leader
leaders,
owner
resource
or
program.
C
This
right,
the
rhythm,
is
also
similar
situation,
so
I
hope
to
share,
but
I'm
not
sure
the
solution,
maybe
you
hope
to
get
ownership
for
that
tom
empire,
but
I'm
not
sure
how
maybe
there's
some
technical
problem
in
here.
A
I
am
not
sure
I'm
trying
to
remember
the
the
history
of
why
that
the
permissions
were
broken
up
that
way,
but
that's
certainly
something
we
can
go
back
and
check
with
with
the
sig
doc
chair
and
leads
and
and
see
if
there's
a
a
way
that
that
can
be
done.
I
think
that's
a
great
issue.
I.
E
Think
this
has
been
brought
it
up
as
a
topic
before
in
the
sick,
docs
meeting
yeah.
I
I
remember
that
jim
and
zach
were
talking
about
this
obviously
yeah,
and
I
think
the
reason
why
the
permission
is
not
handled
properly
is
because
they
are
not
in
the
proper
directory.
I
mean
they
are,
but
you
know
it's
really
seems
like
it's
really
hard
to
separate
the
permission
on
each
file
in
the
same
directory
right.
It
is
kind
of
technical
in.
C
E
B
B
These
pages,
these
files-
you
were
talking
about
the
toml
file,
are
part
of
the
site
configuration
files
right.
I
think
the
sig
signal
chairs
are
reluctant
to
reduce
those
controls
to
every
team,
because
it's
it's
too
easy
to
break
break
the
whole
site.
Maybe.
B
A
Okay,
so
so
yeah,
I
think
timing
is
right
now
that
I
remember
that.
That's
probably
the
reason
that
that,
if,
if,
if
those
ch,
if,
if
they're,
if,
if
done
improperly,
it
can
cause
a
lot
of
damage,
but
maybe
there's
a
way
that
we
can
make
sure
that
if
changes
are
needed
to
be
approved,
that
there's
a
way
to
be
expedited
and
given
priority,
maybe
a
process.
B
B
A
Right
and
but
we
can
still
bring
it
up
at
the
next
sig
docs,
regular
meeting
and
just
say,
hey,
you
know
be
on
the
lookout
that
there
are
times
when
they
need
an
urgent
change
and
and
be
looking
they'll
be
looking
to
send
a
slack
ping
to
the
chairs.
B
Actually
brad,
I
have
a
suggestion
to
the
whole
team,
so
so
every
day
I'm
watching
the
website
get
repo.
I
got
email
notifications
every
a
few
minutes,
but
sometimes
I
just
don't
know
if
a
change
is
about
chinese
localization
or
some
other
languages
from
the
email
list,
because
in
my
email
list
it
only
shows
me
the
title
of
a
pr
from
the
title.
I
cannot
tell
whether
that
pr
is
about
chinese
or
korean
or
japanese,
so
maybe
we
can
propose
some
practice
across
the
community.
E
Yeah
so
you're,
basically
suggesting
that
we
should
add
something
like
brackets.
Then
like
language
like
yes,
as
a
prefix
of
your
yeah.
B
C
B
A
So
that's
an
easy
best
practice
convention
that
if,
if
the
teams
follow-
and
maybe
we
document
in
the
in
in
our
documentation,
would
save
at
least
kind
of
a
lot
of
time
and
probably
others.
E
So
it's
just!
It
is
just
my
opinion,
because
I
I
don't
really
use
email
for
checking
my
request
list.
E
Whenever
I
check,
if
there's
a
new
pro
request
on
github,
I
I
just
use
the
language
tag
like,
for
example,
a
label
yeah
label.
So
here's
not
label
yeah
label,
language,
j,
a.
A
Well,
that's
how
I
do
it
as
well,
but
that,
but
you
and
I
are
using
the
model
of
we,
go
and
check
the
issues
list
and
or
what
have
you
or
the
pr
list.
A
It
would
be
interesting,
the
other
option
would
be
if
it
could
be
added
automatically
right,
so
it
should
know
right.
It's
it's
knowing
is:
is
the
label
getting
automatic?
Is
the
label
getting
added
automatically
based
on
which
repo
which
which
directory
right
so
it'd,
be
interesting?
If
we,
the
other
option,
would
be
to
to
to
maybe
put
that
in
automatically
had
it,
you
know
when
the
pr
comes
in
that
they
would
just
put
a
prefix
or
something
so
that
it
does
show
up
in
the
email
piece
that
might
be
the
other
way.
A
A
So
so
maybe
that's
another
one
we
should
just
follow
up
on.
I
guess
it
depends
on
how
many
people
think
it's
valuable
if
we
can
get
them
to
add
it
in
manually
or
if
it's
you
know
one
of
those
we
should
try
automatically.
I
I
guess
it's
up
to
the
teams,
so
I
mean
coming.
If
you
talk
to
the
chinese
team
and
they
all
agree,
it's
a
good
idea.
At
the
very
least,
though,
all
the
chinese
team
could
do
it
right.
A
D
Okay,
so
basically,
I
also
have
similar
problem
to
gaming.
When,
whenever
I
I
quote
my
emails
and
then
I
need
to
review
some
stuff,
then
there
is
no
titles
on
that,
except
for
japanese,
because
japanese
is
already
doing
that
for
quite
a
long
time,
and
I
noticed
that
it's
it's
really
useful
if
we
can
add
some
kind
of
prefix
to
the
title
of
the
pr,
because
that's
the
one
that
actually
shown.
D
A
A
We
all
want
to
save
time.
So
that's
something
to
think
about
for
the
teams.
I
guess
that's
a
per
team
decision
for
the
simple
solution.
C
A
C
Actually
we
we
discussed
about
this
issue
already
and
people
said
they
hope
to
use
the
poor
language.
I
mean
per
sentence,
so
we
just
followed
our
preference,
but
if.
A
Okay,
I
mean
as
long
as
it's
somewhere
in
the
subject
line
right.
That's
all
that
matters
I
mean
be
nice
if
they
were
all
prefixes,
but
as
long
as
it's
somewhere
as
my
guess,
then
kaiming
or
others
would
know
to
look
for
it.
A
Otherwise,
I
will
see
you
in
a
month.
I
wish
everyone
a
happy
holidays
and
time
off,
if
you're,
taking
it
and
again,
once
again,
a
really
really
productive
meeting
lots
of
good
action
items
here.
So
I'm
gonna
do
the
five
four
three
two
one
and
I'm
gonna
stop
recording
thanks.
Everyone
for
attending.